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

From: Johan Nilsson (johan.nilsson_at_[hidden])
Date: 2004-06-02 02:38:49

Hi,

"Peter Danford" <pdanford_qed_at_[hidden]> wrote in message
news:20040602024428.45768.qmail_at_web60606.mail.yahoo.com...
> I'm not sure other than the reasons regarding optimizations possible with
statically linked libs. I know that there is also some overhead involved in
calling dll functions as opposed to the static counterpart, but this surely
is a small cost. Other than that, I am not sure.

As you are running VS.NET 2003, you could try the (free) community edition
of Compuware's profiler, downloadable from:
http://www.compuware.com/products/devpartner/profiler/default.asp

Instrumenting your application (and boost.thread) should help you to find
out the reason for the performance degradation when using the runtime linked
version.

And, yes, I second the opinion to make a statically linked version
available - even without or with limited support for TSS/TLS.

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

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

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

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.

3. Destruction-time for TSS data would be indeterminate (unless explicitly
clearing things up).

HTH // Johan