Subject: Re: [boost] [thread] thread_specific_ptr performance
From: Stefan Strasser (strasser_at_[hidden])
Date: 2010-01-12 15:23:09
Am Tuesday 12 January 2010 18:36:43 schrieb Peter Dimov:
> strasser_at_[hidden] 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
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;
assert(optr->get() == 0); //fails!
the assertion should not fail.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk