[boost] Re: Re: Thread Lib and DLL

From: Edward Diener (eddielee_at_[hidden])
Date: 2003-03-29 14:04:09

David Abrahams wrote:
> "William E. Kempf" <wekempf_at_[hidden]> writes:
>
>> Russell Hind said:
>>> I'd been wondering this, and heard about TLS issues.  The issues are
>>> only on Windows it appears.  Search for the thread
>>>
>>> "Fwd: Thread-Local Storage (TLS) and templates" by Greg Colvin on
>>> 18/02/2003
>>>
>>> Specifically, the many posts by William Kempf and Edward Diener
>>> discuss the problems on windows with TLS cleanup.
>>>
>>> I do have a question on this issue:  If this problem is only to do
>>> with TLS cleanup when a thread exits, then if all threads are
>>> created when the program starts and only destroyed when the program
>>> exited, then, in practice, could this really be an issue?  I.e. if
>>> we only work like this, could building thread as a static lib cause
>>> problems providing that we don't let threads exit in the middle of
>>> the program?  We're currently really trying to stay clear of any
>>> DLLs.
>>
>> Theoretically at least, I don't see why this would cause a problem.
>> You intentionally leak, but the leak is benign since it occurs only
>> right before the application exits.  But most users won't code this
>> way, nor do I want to have to deal with the support
>> requests/questions this would cause.  So, unless you have some
>> suggestion as to how I can enable this usage with out causing
>> confusion, I'm not sure I'd care to re-enable static builds.  But
>> you could probably fairly easily hack things to build that way
>> yourself.
>
> I don't really understand the issues here, but I was wondering if you
> could reclaim "leaked" TLS resources lazily somehow, by looking for
> unused TLS the next time new TLS is requested.  Just a thought...

The problem lies in the fact that the TLS API only gives one access to the
storage slot for the thread which is being executed. One does not use any
"tag", or identify the thread in any way, when gaining access to a storage
slot for a particular thread. Therefore it is not possible using the Windows
TLS API to gain access to the storage slot for another thread other than the
one currently executing.

Of course one might be able to roll's one own thread local storage
implementation, probably using std::map<> to map a thread-id against storage
areas for a particular thread, etc. etc. which would allow one to gain
access to another thread's storage areas for thread specific data in order
to do lazy reclamation, but one would have to do a good bit of work in order
to accomplish what TLS automatically gives you. Also, of course, one's own
implementation of TLS would not be compatible with the end-user's normal
thread-local storage if that matters.