Boost logo

Boost :

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*.

   BOOST_ASSERT(tss_vec.size() > this->index);
   return *tss_vec[this->index];

   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);

> 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.

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