Am Tuesday 12 January 2010 18:36:43 schrieb Peter Dimov:
strasser@uni-bremen.de wrote:
I guess this was the reason to introduce a "key" in the first place? a similar behaviour could be implemented using the vector-technique. the key would have to be stored in the vector at the allocated index along with the pointer so thread_specific_ptr::get() can decide if the pointer is left-over from a previous thread_specific_ptr or an actual pointer belonging to this thread_specific_ptr, and reset() can destroy it.
This works (at the expense of doubling the vector size, but it would still beat a map). You'd also need the old cleanup function though.
the use of keys in the current implementation is incorrect anyway I think. a unique key that is obtained in the thread_specific_ptr constructor should be used instead. the bug can be triggered by a thread_specific_ptr being allocated at the same address there already was another one: (adding synchronization to this doesn't make a difference) optional< thread_specific_ptr<int> > optr; void other_thread(){ optr=none; optr=in_place(); } int main(){ optr=in_place(); optr->reset(new int); thread(bind(&other_thread)); this_thread::sleep(posix_time::seconds(5)); assert(optr->get() == 0); //fails! } the assertion should not fail.