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

From: Johan Nilsson (johan.nilsson_at_[hidden])
Date: 2004-06-03 02:33:56

"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 performance profiling discussion]
>

[...]

>
> > I've in the past made a solution based on lazy cleanup
> > of previously allocated TLS data - i.e. when someone attempts to
> alloc a TLS
> > (aka TSS) slot/data, the currently invalid data (belonging to an
> > "ex-thread") is deleted. This requires some metadata to be globally
> > available to all threads, and that this data is tagged with the
> owning
> > threads id, but is certainly doable.
>
> I'll have to think about this.

Ok, please also see my comment below on period tss data cleanup.

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

An alternative could be to have Boost.Threads automatically create a
background thread to periodically collect unowned thread-specific data. 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?

That might anyway not be an issue as this is a platform specific issue only
as this special support should only get compiled if running under Windows
anyway.

[...]

>
> Boost.Threads now uses only one real TLS slot no matter how many
> thread_specific_ptrs you create, so this shouldn't be a problem.

Great.

>
>
> > 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. Thread B
can still create it's own data, 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.

// Johan