Re: [boost] [thread] thread_specific_ptr performance

Subject: Re: [boost] [thread] thread_specific_ptr performance
From: strasser_at_[hidden]
Date: 2010-01-12 08:15:30

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