Re: [boost] [thread] thread_specific_ptr performance

Subject: Re: [boost] [thread] thread_specific_ptr performance
From: strasser_at_[hidden]
Date: 2010-01-12 10:58:39

Zitat von Vicente Botet Escriba <vicente.botet_at_[hidden]>:
> Peter Dimov-5 wrote:
>>
>> Vicente Botet Escriba wrote:
>>> For me it is unacceptable to use reallocation of the vector on the
>>> operator*.
>>
>> Operator* has a non-NULL precondition and doesn't need to reallocate.
>> reset() does, but only if you set a thread_specific_ptr that has been
>> created after the thread has started.
>>
>>
> I was responding to the proposition of Stefan, not to the current
> implementation.

peter´s right, no reallocation in operator*.

thread_specific_ptr::operator*(){
   BOOST_ASSERT(tss_vec.size() > this->index);
   return *tss_vec[this->index];
}

thread_specific_ptr::get(){
   if(tss_vec.size() > this->index) return tss_vec[this->index];
   else return 0;
}

thread_specific_ptr::reset(T *ptr){
   auto_ptr aptr(ptr);
   if(tss_vec.size() <= this->index) tss_vec.resize(this->index+1);
   tss_vec[this->index]=aptr.release();
}

> My concrete example is to access the current transaction on a Software
> Transaction Memory. This operation can be required frequently. You should

but reallocation only happens once per thread, on first call to reset().

> I have no access to the code now. Please,could you show where the current
> implementation allocates and use a mutex on the operator*.

probably also only on reset(), the code is in libs/src/pthread/thread.cpp.
it inserts an element into a std::map, which allocates, which acquires  
a mutex.

> A library could not know if its users work on a Boost.Thread or on a native
> thread. So thread_specific_ptr needs to work in both cases. The current
> implementation of thread_specific_ptr satisfy already this. Any alternative
> proposal need to satisfy this requirement also.

ok, I wasn´t sure.