----- Original Message ----- From: <strasser@uni-bremen.de> To: <boost@lists.boost.org> Sent: Tuesday, January 12, 2010 4:58 PM Subject: Re: [boost] [thread] thread_specific_ptr performance Zitat von Vicente Botet Escriba <vicente.botet@wanadoo.fr>:
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*. <snip code>
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. _______________________________________________ Stefan, I have never talk about reset function but the operator*. Just quoting yourself "thread_specific_ptr operator*: one branch to make sure the vector is large enough(a new thread_specific_ptr might have been created by another thread), one indirection. constant-time average, linear to vector if reallocation is necessary. but that can only happen when a new thread_specific_ptr was created."
From this I deduce that the operator* you were proposing did a reallocation. Please don't mix allocation on the map and reallocation of the vector you were proposing.
Vicente