Subject: Re: [boost] [thread] thread_specific_ptr performance
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.
one branch to make sure the vector is large enough(a new
thread_specific_ptr might have been created by another thread), one
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk