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:40:28

Stefan Strasser-2 wrote:
> 
> 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.
> 
> struct page{
>   user_ptr ptr[0x10000];
> };
> 
> page *pages[0x10000];
> 
> operator*(){
>   size_t pagenr=this->index & 0xffff0000];
>   page *p=pages[pagenr];
>   if(!p) p=pages[pagenr]=new page;
>   return p[this->index & 0xffff];
> }
> 
> if 64K*sizeof(user_ptr) per page is too much that can be reduced by
> setting a 
> reasonable maximum below 4 billion or by using a third indirection.
> 
This implementation don't suffer of linear or logarithmic complexity a far
as the page allocations is linear.
An implementation based on pages could satisfy my requirements.

> could you ellaborate on your case that can't accept reallocation?
> I can't think of a case. as long as there is an allocation (and there is
> one 
> in the current implementation, too) there's a mutex lock and no guarantee
> on 
> the time it takes to return anyway.
> 
> 
My concrete example is to access the current transaction on a Software
Transaction Memory. This operation can be required frequently. You should
have this also on your Persistent library. IMO, the access to the current
transaction must have a linear complexity.

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

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