[boost] Re: Re: Thread lib (good reason for static)

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-06-03 10:09:17

"Johan Nilsson" <johan.nilsson_at_[hidden]> wrote in message
news:c9mk92$815$1_at_sea.gmane.org...
>
> "Michael Glassford" <glassfordm_at_[hidden]> wrote in message
> news:c9kodd$krt$1_at_sea.gmane.org...
> > "Johan Nilsson" <johan.nilsson_at_[hidden]> wrote in message
> > news:c9k069$9jf$1_at_sea.gmane.org...

[snip]

> >
> > > 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
it.
> > 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
have
> > 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
this, of
> > having Boost.Threads create a "pseudo-dll" on the fly that can
detect
> > when threads go away and tell Boost.Threads about it.
> >
>
> Could this cause problems in the future, when Windows will make use
of the
> protect-memory-from-execution functionality in recent Intel
processors
> (sorry, I just don't remember the proper name)?

I don't know. I was worried about that myself, but haven't looked into
it yet.

> An alternative could be to have Boost.Threads automatically create a
> background thread to periodically collect unowned thread-specific
data.

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

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.

[snip]

> > > 2. Operating system's reuse of thread id's. This could (in
theory)
> > 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
data
> > 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
(id:1)
> 5. Thread B creates thread_specific_ptr; this is the first time so
the
> implementation now also tries to perform a 'lazy' cleanup of any
unowned
> data. There are still data allocated by Thread A, but this is mapped
through
> 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
using it?

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
above.
>
> Yes, but that's still forcing the user to use a "special" dll just
for that
> purpose.

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.

Mike