Re: [boost] [thread] thread_specific_ptr performance

Subject: Re: [boost] [thread] thread_specific_ptr performance
From: Peter Dimov (pdimov_at_[hidden])
Date: 2010-01-13 08:34:40

James Mansion wrote:
> Peter Dimov wrote:
>> I don't think that any implementation gives you this constant time
>> guarantee if you continually create thread-specific variables.

> Why does any application, ever, need to even be allowed to
> 'contonually create thread-specific variables' without being
> considered badly broken?
> Thread-specific variables are a proxy for partitioned global data -
> and that doesn't get created and destroyed except with DLL loading and
> unloading.  And DLL unloading somewhat extremely dodgy in C++ as it
> is.

__thread, __declspec(thread) and C++0x thread_local variables are indeed 
restricted to global scope. But boost::thread_specific_ptr isn't, and people 
have been using it as a class member. I can see nothing inherently wrong 
with such an use, even though it isn't "conventional".

> If you have object instances (say, some sort of rule interpreter)
> which wants to have thread-specific state then really its better handled
> with a thread-specific map between the object instance address and its
> state instance.

This is basically what thread_specific_ptr currently does.