Zitat von Anthony Williams <anthony.ajw@gmail.com>:
I find this a rather severe design bug. I will propose you to change the severity to showstopper as we can not use thread_specific_ptr other than statically. Anthony, what do you think?
I think that using a thread_specific_ptr as an automatic variable is incorrect usage. The lifetime of the variable is strictly limited to the duration of the function call, and each thread that calls the function will get its own copy of the thread_specific_ptr.
you're probably referring to Edd's test case. it's only that, a test case, the bug can be triggered in other scenarios, including thread_specific_ptrs being allocated at the same address on the heap, where multiple threads have access to it. it might be unlikely but it is pretty much unpredictable and depending on the platforms heap allocator, which is never a good thing.
It is primarily intended for use with static storage duration.
if only static usage is intended you might be interested in the static_thread_specific_ptr I use here, whose interface enforces static usage: https://svn.boost.org/svn/boost/sandbox/transaction/boost/transact/detail/st...