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

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-02-24 22:38:35

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

This is the MS way, not the "standard" way.  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.  As is
calling any routines that load/unload a DLL.  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 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 ;).  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.

-- 
William E. Kempf