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.
> 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
> 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.
-- 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk