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

From: Edward Diener (eddielee_at_[hidden])
Date: 2003-02-26 17:48:50

William E. Kempf wrote:
> Edward Diener said:
>> William E. Kempf wrote:
>>> Edward Diener said:
>>>> William E. Kempf wrote:
>>>> I still don't think it is a TLS issue but rather a thread cleanup
>>>> issue and the restrictions imposed by MS's design of that
>>>> situation. So I can well understand your chagrin at the tricks you
>>>> must do in order to cleanup internal thread data when a thread
>>>> exits under Windows.
>>>
>>> That's a minor fine hair your splitting.  What's the difference
>>> between "a TLS issue" and a "thread cleanup issue" of TLS data?
>>
>> Because it is a thread cleanup issue of any thread specific data, not
>> just TLS. No matter what the data that exists for a thread when the
>> thread is exited, it musty be cleaned up efficiently. A user could
>> have objects associated with only a particular thread and if the
>> thread ends, it must be able to cleanup while other threads continue
>> running. The fact that MS says no to this in DLL_THREAD_DETACH, that
>> you are effectively blocking other threads in the process until you
>> exit the DllMain routine, is for me the central weakness.
>
> What forms of "thread specific data" are there besides TLS?  How does
> DllMain play into how you clean up such data?

One could dynamically create an object in a DLL that exists for one thread
and not another, depending on what the thread is doing, and hold a pointer
to that data mapped to a particular thread. Then when the thread exits in
the DLLMain routine, one could look to delete that object which may in tuern
have other consequences. I am not saying that this is the usual way of using
threads, but just posing the idea that TLS itself may not represent all of
the data which a thread wants to delete when it exits. If it is supposed
that it is the only reliable way of creating thread-specific data, and any
other method of using thread-specific data is bad and prone to error, then I
agree with you that TLS under Windows can be considered as part of the issue
of cleaning up data when a thread exits.

Again we are nitpicking over an issue in which I think we both agree that
the cleanup of thread-specific data, however we define it which at present
is essentially TLS, when a thread ends is not designed effectively in
Windows.

DllMain comes into it because MS's design for passing through DllMain when a
thread exits is that no other thread can run until your code in
DLL_THREAD_DETACH in DllMain is finished. If another thread could run,
either because of blocking on synchronization or just pre-emption, then
synchronization and LoadLibrary issues probably wouldn't come into effect
and the headaches you are experiencing in Boost.Threads wouldn't be
happening. Again my guess, without knowing the gory details of Windows
DllMain code and probably not caring to know, is that DllMain, and its
internal code, is not reentrant and therefore the only guarantee that keeps
another thread from entering it while one thread is already in the midst of
it, is the draconian anti-effective-cleanup measures of which you are
familiar.

>
>>>  And
>>> if you look back, I said I wouldn't call it "broken", just that the
>>> "implementation has serious design issues".  So it looks like we're
>>> in agreement now.
>>>
>>> Want to join in my mini campaign to convince MS to fix this one?
>>
>> As long as the suggested fix is to allow thread cleanup without the
>> current restructions on synchronization or DLL loading/unloading,
>> sure. I don't think you are going to change anything in the way that
>> TLS currently works nor should you. I am going to guess that MS is
>> aware of this issue of thread cleanup and that the main fix on their
>> part would be to allow re-entrancy in the current DllMain routine,
>> which of course may be a big job on their part given the amount of
>> underlying intertwined code.
>
> I have to disagree.  First, I don't think you *can* solve the
> reentrancy problems with DllMain.  Second, even if you could, DllMain
> is the wrong solution for cleanup.  Something as simple as a thread
> exit routine would be a much better "partial" solution, though it's
> silly not to add this directly to TlsAlloc() (or a TlsAllocEx() to
> keep backwards compatibility).

While I agree with you that an effective thread exit routine rather than
DllMain's DLL_THREAD_DETACH is a better design, I think you must realize
that you are dealing with a company with millions and millions of developers
and any serious change in the way things are designed will be very slow to
happen. In the meantime I will settle for the less optimal, but present
solution, to perhaps be effectively fixed. Of course if MS wants to go whole
hog and present your much better solution, or a similarly better solution,
outside of DllMain, that would be fine.

>
>> The other solution(s) involves some sort of callback
>> as you suggested, or some other way to ensure that a thread can be
>> exited cleanly without blocking other threads from running in the
>> meantime, whether in an executable, a static LIB, or a DLL.
>>
>> Knowing MS from their track record, a campaign to get them to change
>> anything entails working closely with one or more of their techies
>> who can actually understand the issues involved and get the changes
>> to be seriously considered. Just voicing displeasure in any public
>> way won't do anything. If there is a VC++ rep who now works closely
>> with Boost to ensure VC++ .NET conformance, he's the guy I would
>> "badger" first, and then through him you might be able to get to
>> other MS techie employees.
>
> I can give you some names.  I could also give some e-mail addresses,
> though that might be considered bad netiquette.  But MS *does* have
> someone who's supposed to champion for us developers... Herb Sutter.
> If you want to campaign for this, send him a polite e-mail and I'm
> sure he'll discuss this with the appropriate folks at MS.

I have an address for Herb Sutter from CUJ but I don't know if that is the
most effective for reaching him on this issue. If you have another one, I
will be glad to use it and argue for the need of thread cleanup which
doesn't block other threads from running at the same time and.or prevent
synchronization. I don't mind adding my voice to an issue which has obvious
drawbacks.