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
__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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk