Edward Diener said: > William E. Kempf wrote: >>> You can clean up your own TLS index ( or indices ) in your DllMain >>> routine when the seond parameter is DLL_PROCESS_DETACH, meaning that >>> your process is being exited. AFAIK this is the standard way to do >>> this. >> >> (Note: The issue is more with cleaning up TLS data then with cleaning >> up TLS indices/slots. So we're really talking about >> DLL_THREAD_DETACH here.) > > Then perhaps the weakness is not really with TLS on Windows but rather > with limitations to actions one can perform at DLL_THREAD_DETACH time.
No, the issue is that the only mechanism provided for TLS cleanup is to hook DllMain, or to explicitly clean up the data in the thread before it exits. The former is unusable in several cases, while the latter can only be done if you control the creation of the thread. > Would you describe these issues specifically ? I did, below. >> This is the MS way, not the "standard" way. > > "This" referring to what above ? Using DllMain to cleanup TLS data. >> And it's full of issues. >> You are quite limited in what you can safely do within DllMain. Any >> calls to synchronization routines is likely to deadlock the entire >> process. > > I agree that this is so. You can't sit and wait until some other thread > has done something, via a Windows synchronization primitive, when you > are processing DLL_THREAD_DETACH. What is the situation where this is > necessary ? There are numerous situations where this is necessary. For example, the cleanup mechanism in both Boost.Threads and pthreads-win32 use mutexes, which can potentially cause *process* deadlock. If the TLS data is shared across threads, or references data shared across threads, or simply calls a routine that does synchronization in the cleanup, all of which are not that uncommon, and some of which are hard for the programmer to avoid (do you know what routines do synchronization internally?), you risk deadlock. >> As is calling any routines that load/unload a DLL. > > The workaround is not to dynamically load/unload a DLL as part of thread > processing. Do you know what routines do this as part of their implementation? To quote the MSDN "Calling imported functions other than those located in Kernel32.dll may result in problems that are difficult to diagnose." And since a very large number of Win32 API functions are imported... I think you see the issue. > Yes, it is cleaner to do so when one only needs a DLL for a > specific time but the overhead of statically linking a DLL into a > process instead is minimal, although I agree that dynamic loading is > often a cleaner design. I do agree with you that the inability to > dynamically load and unload a DLL at DLL_THREAD_ATTACH/DLL_THREAD_DETACH > is an unfortunate imposition and that this is poor design on MS's part. > I am still not clear whay this is so and why this limitation exists on > Windows. I honestly don't care. The only time I've ever found this design to be unusable is when dealing specifically with the cleanup of TLS data, which would be much better implemented as a registered cleanup routine in the first place. Fix this, and I don't care about this artifact of the DLL system on Win32 platforms. >> There's >> also the issue of forcing the use of a DLL with this scheme, which >> many users rightfully dislike (this is why there are so many thread >> creation routines on Windows). > > I could be mistaken but I believe that TLS works just as effectively in > static LIBs as it does with DLLs. The difference is that one must do > manual initialization routines and finalization routines of TLS data for > different threads, as opposed to what one may do automatically using > DLL_THREAD_ATTACH/DLL_THREAD_DETACH. But certainly one is not forced to > use only DLLs or only static LIBs if the implementation supports both. Initialization isn't really an issue, as you can do lazy initialization (synchronization issues aside, as they are solvable). It's the finalization that's an issue, and it's resulted in the numerous thread creation routines and the rules for when to use which one. If you call any C RTL routines (which may allocate TLS) you can't call CreateThread, but must instead call _beginthread(ex). Likewise, if you call any MFC routines you can't call CreateThread or _beginthread(ex) but instead must call AfxBeginThread, lest you leak TLS data allocated by these routines. This is an issue for Boost.Threads, which has it's own thread creation routines, because I don't know how a user will use the thread. It's a problem for other libraries if they have thread creation routines, or have user registered callbacks executed by the threads created by the library. It's a problem if you want to make use of the built in Win32 thread pooling mechanisms, since those threads will be created using CreateThread. And so on. >>>> I won't be as critical as Alexander, but I will agree that the MS >>>> TLS implementation has serious design issues which need to be >>>> corrected. >>> >>> OK, this isn't the place to debate Windows TLS, but I have not run >>> into such design issues myself. >> >> You have, you just weren't necessarily aware of it ;). > > No, I haven't for what I was doing <g> but that doesn't mean you or > others haven't. It seems that the problems are MS's design of what one > can do in DLL_THREAD_ATTACH/DLL_THREAD_DETACH itself instead of in TLS. > If you can point out specific problems in Boost.Threads I would be glad > to hear about it. Problems in Boost.Threads: 1) We must use a shared library design on Win32, which is something several users (rightfully) have problems with, but this is the only way to implement thread_specific_ptr<>. (Well, I could also use the "solution" MS has used, i.e. you must use Boost.Threads thread creation routines if a thread can ever call a routine that uses TLS allocated by Boost.Threads, but this is fragile and not very usable in a lot of situations today, and will be even more so for every thread creation routine added this way.) 2) User cleanup routines can't safely use any synchronization primitives. 3) User cleanup routines can't safely use any imported functions from any DLL other than kernel32.dll. 4) 2 & 3 can be done with out the knowledge of the user in many circumstances. 5) The DLL from (1) must be statically linked. Not necessarily a real issue, but something unusual that the users must be aware of. -- William E. Kempf _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
