Re: [boost] [thread] thread_specific_ptr performance

Subject: Re: [boost] [thread] thread_specific_ptr performance
From: Vicente Botet Escriba (vicente.botet_at_[hidden])
Date: 2010-01-12 10:48:23

Stefan Strasser-2 wrote:
> 
> Am Tuesday 12 January 2010 16:33:31 schrieben Sie:
>> Am Tuesday 12 January 2010 15:17:05 schrieb Vicente Botet Escriba:
>> > > 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.
>> > >
>> > > I think the branch also could be avoided with some effort and a
>> second
>> > > indirection(using pages to avoid reallocating and making sure the
>> page
>> > > exists in each thread on thread_specific_ptr construction) but to me
>> > > the branch is acceptable.
>> >
>> > For me it is unacceptable to use reallocation of the vector on the
>> > operator*. More, any non-constant time operator* don't satisfy my
>> > requirements for some specific contexts.
>>
>> I'd prefer reallocation, but reallocation can be avoided using pages at
>> the
>> cost of a second or third indirection.
> 
> plus, as I've said it could be possible to do the work on construction of
> a 
> thread_specific_ptr for all threads so there is no branch in operator*.
> 
I have not said nothing about that. I want just a constant time operator*().

> however, that depends on if the boost thread API can be used together with 
> other thread APIs, because then the pages must be initialized on start of
> a 
> new thread. so only boost threads could access thread_specific_ptrs, 
> accessing a thread_specific_ptr from a natively created thread would fail.
> 
> 

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.

Vicente
-- 
View this message in context: http://old.nabble.com/Boost-library-submission-%28poll-for-interest%29-tp27020800p27129648.html
Sent from the Boost - Dev mailing list archive at Nabble.com.