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.