Boost logo

Boost :

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
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(){

int main(){
  optr->reset(new int);


  assert(optr->get() == 0); //fails!

the assertion should not fail.

Boost list run by bdawes at, gregod at, cpdaniel at, john at