Re: [boost] [thread] thread_specific_ptr performance

Subject: Re: [boost] [thread] thread_specific_ptr performance
From: Stefan Strasser (strasser_at_[hidden])
Date: 2010-01-09 06:23:57

Am Saturday 09 January 2010 13:22:23 schrieb Andrey Semashev:
> In short:
>
> * The TLS must have static duration.
> * Only POD types are supported as TLS declared with __declspec(thread).
> * It doesn't work if TLS is defined in a delay-loaded dll.

I see. but while that is a good reason to have a std::map (or unordered_map) 
in boost, I still don't get why you can't use thread local storage for saving 
the pointer to the map (i.e. the result of get_current_thread_data()).

I can't say I understand all the details of the current implementation, but in 
case pthread_setspecific etc. needs to be kept for some reason related to 
construction/destruction, it seems to me at the very least the result of 
get_current_thread_data() could be cached in a thread-local variable.

that would speed up thread_specific_ptr::get() 5-fold according to my 
profiling.

Am Saturday 09 January 2010 12:48:39 schrieb Rutger ter Borg:
> Stefan Strasser wrote:
> > implementing this requires a call to thread_specific_ptr::get() on each
> > operation to obtain the active transaction.
> >
>
> Isn't this under the assumption that such a container should be thread-safe
> by default?

even if you exclusively lock the container before every access, even if you 
stop all other threads, the container still needs to obtain the active 
transaction, set by the constructor of transaction_scope in your example.

the only assumption is that there is more than one thread that created a 
transaction_scope object, but I think you have to assume that.

Am Saturday 09 January 2010 01:22:25 schrieb vicente.botet:
> > the proposal of C++0x thread local storage is about 10 pages:
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2659.htm
>
> Well the proposal may have 10 pages but the syntactical addition is quite
> simple, the problem is that each compiler has each own syntax.

hiding the syntax behind a BOOST macro shouldn't be a problem, but I doubt 
both extensions (and intel's, and...) have the same semantics regarding 
construction, destruction, what types can be used etc.

> Have you made some mesurements comparing thread_specific_ptr and __thread
> for example? If there is a big difference maybe you could make a ticket
> then.

no I have not, but there is no need to. accessing a

__thread T *ptr;

results in something like:

movl gs:ptr,%eax