tag:blogger.com,1999:blog-5246987755651065286.post1188248918160372462..comments2024-02-22T16:15:42.388-08:00Comments on cbloom rants: 07-09-11 - TLS for Win32cbloomhttp://www.blogger.com/profile/10714564834899413045noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-5246987755651065286.post-41845566255192470332011-07-15T10:29:08.492-07:002011-07-15T10:29:08.492-07:00Hmm.. well, I've only glanced at it so maybe y...Hmm.. well, I've only glanced at it so maybe you can teach me how it works.<br /><br />I see some wacky stuff in src\win32\tss_pe.cpp files but it's not at all clear how it works. It seems like maybe it's latching into MS's __declspec(thread) TLS functionality.<br /><br />It also looks like there is a tss_pe and a tss_dll and you have to choose the right one. That spoils the whole point, which is that you want to be able to build .lib code that works whether it is in a DLL or not. If you know at compile time whether you are in a DLL or not, then the whole problem is completely trivial and I have no idea why they're using such complicated mechanisms (you can just use MS's __declspec(thread) if you know you're in a LIB and avoid this whole mess!).<br /><br />To be clear, the only reason that anyone would ever want to use this funny TLSVar nonsense is because you can't use the compiler-provided __thread mechanism, which is better in every way than these hand-cooked systems.<br /><br />I *do* see that they manually call the thread exit callbacks with a shim for boost threads ; in src\win32\thread.cpp<br />"thread_start_function" is a shim that runs the thread func then does the cleanup, which is why I thought that was the only mechanism.cbloomhttps://www.blogger.com/profile/10714564834899413045noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-54989859462508082082011-07-15T09:39:07.980-07:002011-07-15T09:39:07.980-07:00"They use a thread shim to do cleanups. .... ..."They use a thread shim to do cleanups. .... So I can't just add TLS to any thread using boost"<br /><br />That's not true. The code in tss_pe.cpp hooks the Win32 thread-exit callbacks, so it is called when ANY thread exits. This is precisely so that you CAN use boost TLS stuff without using boost::thread to manage your threads.Anthony Williamshttps://www.blogger.com/profile/12888842046584695509noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-45906062319663524062011-07-14T09:54:57.092-07:002011-07-14T09:54:57.092-07:00" Anyway, the specific issues that I was thin..." Anyway, the specific issues that I was thinking of were the cleanup issues. You've said you don't care, since your threads run until the end of the process, but for those that do care, boost takes care of it for you. The code to invoke callbacks on thread exit is in tss_dll.cpp and tss_pe.cpp. "<br /><br />Yeah. They use a thread shim to do cleanups. That's okay and very easy to write yourself, but it means it only works for threads that are created by boost::thread.<br /><br />So I can't just add TLS to any thread using boost, it's the typical boost thing where you have to buy into the whole system for it to work right.<br /><br />Anyhoo, yeah, people should look at Boost. But I think the vast majority of people in games are not Boost lovers.cbloomhttps://www.blogger.com/profile/10714564834899413045noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-82255915724900584292011-07-13T23:52:12.259-07:002011-07-13T23:52:12.259-07:00Yes, boost TLS uses a linked list in order to avoi...Yes, boost TLS uses a linked list in order to avoid overuse of TLS slots. If you don't like that aspect, it's easy to change.<br /><br />Anyway, the specific issues that I was thinking of were the cleanup issues. You've said you don't care, since your threads run until the end of the process, but for those that do care, boost takes care of it for you. The code to invoke callbacks on thread exit is in tss_dll.cpp and tss_pe.cpp.Anthony Williamshttps://www.blogger.com/profile/12888842046584695509noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-84859800239469614272011-07-11T08:45:55.118-07:002011-07-11T08:45:55.118-07:00"You could always just use boost::thread_spec..."You could always just use boost::thread_specific_ptr, which handles these issues for you (or steal the code for your own implementation)."<br /><br />Well, I had a look, and it just doesn't look very good.<br /><br />They appear to use a linear linked list search to find a given key/data pair in their one TLS slot.<br /><br />Accessing a TLS var should not be orders of magnitude slower than accessing a local var.<br /><br />If you've bitten off the bullet and are using boost::thread it's okay, but as a source of code to grab it's pretty gross.cbloomhttps://www.blogger.com/profile/10714564834899413045noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-29452680282751408182011-07-11T00:17:45.577-07:002011-07-11T00:17:45.577-07:00You could always just use boost::thread_specific_p...You could always just use boost::thread_specific_ptr, which handles these issues for you (or steal the code for your own implementation).Anthony Williamshttps://www.blogger.com/profile/12888842046584695509noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-59848491407094190762011-07-10T12:42:10.808-07:002011-07-10T12:42:10.808-07:00SUPER *cough* UX probably beats it...
For a low th...SUPER *cough* UX probably beats it...<br />For a low thread count using the tread-ID in hashmap was fastest.Joerghttps://www.blogger.com/profile/13111217588104575785noreply@blogger.com