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 09:17:05

Stefan Strasser-2 wrote:
> 
> Zitat von Anthony Williams <anthony.ajw_at_[hidden]>:
> 
>>> I really hope Anthony will take a look at it and come up with a
>>> vector-based solution. Or I can finish the patch myself, if it has any
>>> chance of getting into SVN. Anthony?
>>
>> Boost 1.35 used a vector for the thread_specific_ptr data, but there
>> were complaints about the excessive memory usage. The map version has a
>> smaller memory footprint.
> 
> 1.35 also uses the thread_specific_ptr´s address as key, but searches  
> for it in a list. and as far as I can see nodes of that list are not  
> reused, which is probably the reason for the complaints.
> 
> what we meant above was allocating an index on thread_specific_ptr  
> construction, not using the address as a key into a vector.
> those indexes could be reused as andrey indicated by maintaining a  
> free-list, so there is no excessive memory usage.
> 
> 
> Zitat von Vicente Botet Escriba <vicente.botet_at_[hidden]>:
>> I would provide the thread_specific_ptr interface at several levels:
> 
> I don't see why that would be necessary.
> 
1st level provide the best performances that can be needed in some contexts.

Stefan Strasser-2 wrote:
> 
> the vector can be reallocated at any time without a mutex since it is  
> thread-specific, so your "2nd level" can be used for an unlimited  
> number of thread_specific_ptrs.
> 
> thread_specific_ptr constructor: mutex lock, either getting an index  
> from the free-list or using end of vector. constant-time.
> 
> thread_specific_ptr destructor: mutex lock, add index to free-list.  
> constant-time.
> 
> 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.

Vicente

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