From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-06-03 10:09:17
"Johan Nilsson" <johan.nilsson_at_[hidden]> wrote in message
> "Michael Glassford" <glassfordm_at_[hidden]> wrote in message
> > "Johan Nilsson" <johan.nilsson_at_[hidden]> wrote in message
> > news:c9k069$9jf$1_at_sea.gmane.org...
> > > It could also be possible to expose a manual TLS-data
> > "garbage-collection"
> > > routine, e.g. "collect_tss_data", for the user's really nedding
> > Not
> > > beautiful, but considering the options ...
> > I had thought of something like this, too. Or of exposing cleanup
> > functions that could be called from the user's dllmain (if they
> > one) rather than requiring Boost.Threads to have its own dllmain
> > function to detect when threads go away. And there's the idea that
> > Roland proposed some time ago, which could be built on top of
> > having Boost.Threads create a "pseudo-dll" on the fly that can
> > when threads go away and tell Boost.Threads about it.
> Could this cause problems in the future, when Windows will make use
> protect-memory-from-execution functionality in recent Intel
> (sorry, I just don't remember the proper name)?
I don't know. I was worried about that myself, but haven't looked into
> An alternative could be to have Boost.Threads automatically create a
> background thread to periodically collect unowned thread-specific
This could also be used in addition to lazy cleanup instead of as an
alternative, and seems to have the same problems.
> Now if boost threads could have priority assigned to them to make
> this a (corresponding to) THREAD_PRIORITY_IDLE thread - is that in
The (unfinished) changes on the thread_dev branch do implement thread
priorties. They won't make it into the next Boost release, but I hope
they will be in the one after that.
> > > 2. Operating system's reuse of thread id's. This could (in
> > cause
> > > data to be hanging around longer than necessary, but should
> > otherwise not be
> > > causing problems as each thread should only be able to access
> > created
> > > by themselves.
> > I can see reuse of thread ids being a problem, but I'm not sure I
> > understand the rest of this.
> Highly theoretical:
> 1. Thread A is created with id:1
> 2. Thread A" creates thread_specificic_ptr (first time), implicitly
> allocating TLS slot.
> 3. Thread A exits
> 4. Thread B is created, gettting the recycled id of the first thread
> 5. Thread B creates thread_specific_ptr; this is the first time so
> implementation now also tries to perform a 'lazy' cleanup of any
> data. There are still data allocated by Thread A, but this is mapped
> the thread's id and so can't be detected as ready for collection.
I follow as far as this.
> Thread B can still create it's own data,
How does thread B know that it needs to create its own data--i.e.,
what prevents it from thinking that thread A's data is its own and
Here's a specific case I have in mind: the implementation of the
thread class on the thread_dev branch. In this implmemtation, the
thread class has become a handle class that holds a reference-counted
pointer to a thread_data class. When a thread class is created, it
gets access to the thread_data class for the thread using a global
static thread_specific_ptr. In the scenario you outline above, when a
thread object created on Thread B tries to access its thread data
through this thread_specific_ptr, it will get the thread data for
thread A, which is a Bad Thing.
> but Thread A's won't be collected until
> after Thread B has exited (and another thread attempts to create
> thread-specific data - causing lazy cleanup).
> > > 3. Destruction-time for TSS data would be indeterminate (unless
> > explicitly
> > > clearing things up).
> > Unless using one of the alternative dllmain schemes I mentioned
> Yes, but that's still forcing the user to use a "special" dll just
Not necessarily. If the user's code is in a dll, its own dllmain could
be used; or the dllmain of the "pseudo dll" that is created on the fly
could be used.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk