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

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-06-02 09:34:06

"Johan Nilsson" <johan.nilsson_at_[hidden]> wrote in message
news:c9k069$9jf$1_at_sea.gmane.org...

[snip performance profiling discussion]

> [following is windows-specific stuff]
>
> I seem to recall that the reason for requiring a dynamically linked
version
> was solely for automatically cleaning up thread_specific_ptr's at
thread
> exit - is that right?

Yes.

> 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.

> 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.

Unfortunately, I still haven't been able to spend much time actually
trying these ideas out. Most of my recent Boost time has been spent
working on finishing the conversion of Boost.Threads docs to BoostBook
format and updating them.

> There are a few potential problems though (off the top of my head):
>
> 1. Performance - each creation of thread-specific data required
exclusive
> access to the metadata. If this is a real issue or not depends on
the
> real-world scenario.

Yes.

> Developers sensitive to this should anyway try to
> create only one thread_specific_ptr to host all their TSS data.
Also, TLS
> slots are a limited resource (especially under earlier NT versions).
> Or is this automatically managed by the current TSS implementation?

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.

> 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.

> 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.

Mike