Subject: Re: [boost] [thread] thread_specific_ptr performance
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2010-01-09 07:58:35
On 01/09/2010 02:23 PM, Stefan Strasser wrote:
> Am Saturday 09 January 2010 13:22:23 schrieb Andrey Semashev:
> 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.
The pointer to the thread-specific data is stored in TLS, last time I
checked. And there's no difference in terms of performance in how you
store the pointer - via __thread specifier or by manually calling
pthread APIs. In case of __thread the compiler will generate the
necessary calls to pthread for you, that all you win, AFAIU.
> that would speed up thread_specific_ptr::get() 5-fold according to my
Hmm, that's unexpected. Could you post a patch to test with?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk