[boost] Re: Re: Re: Thread-Local Storage (TLS) and templates

From: Edward Diener (eddielee_at_[hidden])
Date: 2003-02-24 23:57:03

William E. Kempf wrote:
> Edward Diener said:
>> "William E. Kempf" <wekempf_at_[hidden]> wrote in message
>> news:1478.167.16.75.11.1046125028.squirrel_at_frodo.kempf-ville.com...
>>>
>>> Edward Diener said:
>>>> "Alexander Terekhov" <terekhov_at_[hidden]> wrote in message
>>>> news:3E5A1583.775485FC_at_web.de...
>>>>>
>>>>> Ken Hagan wrote:
>>>>>>
>>>>>> Alexander Terekhov wrote:
>>>>>>>
>>>>>>> I, for one, believe strongly that "&k" is nothing but
>>>>>>>
>>>>>>>     "static_cast<typeof(k)*>(pthread_getspecific(__k_key));"
>>>>>>>
>>>>>>> It *isn't* a compile-time constant (just like &errno isn't a
>>>>>>> compile time constant).
>>>>>>
>>>>>> MSVC has no pthread_getspecific(), so I venture to suggest that
>>> your
>>>>> belief probably isn't valid for that compiler.
>>>>>
>>>>> Uhmm. In return, I venture to suggest that MS-TLS can and shall be
>>> characterized as ``utterly busted.''
>>>>>
>>>>> "If a DLL declares any nonlocal data or object as
>>>>>  __declspec(thread), it can cause a protection fault if
>>>>> dynamically loaded."
>>>>
>>>> This is well-known by many and has never been hidden by MS. It
>>> doesn't mean __declspec(thread) is busted, it just means that it is
>>> limited to only those cases in which the DLL is not dynamically
>>> loaded, which is the vast majority of cases. Of course to make TLS
>>> completely foolproof, one does not use __declspec(thread) but
>>> instead one uses the Win32 TLS API functions instead.
>>>
>>> Where you run into issues with TLS cleanup ;).
>>
>> Such as ?
>>
>> 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. Would you
describe these issues specifically ?

>
> This is the MS way, not the "standard" way.

"This" referring to what above ?

>  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
?

>  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. 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.

>  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.

>
>>> 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.

>  Again, I
> point you to the various thread creation routines as the number one
> issue that we've all encountered.  If you've needed to do complex
> cleanup, or wanted to not have to deal with a DLL, then you've run
> into the other problems more directly.  This has been the biggest
> issue with implementating thread_specific_ptr<> for me, and what we
> have today is quite ugly and fragile.
>
> And I do think it's a proper place to debate Windows TLS.  It directly
> effects Boost.Threads, and the more people we make aware of the
> problems, the more likely something will be done about it.