Re: [boost] [thread] thread_specific_ptr performance

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