Stefan Strasser-2 wrote:
Zitat von Anthony Williams <anthony.ajw@gmail.com>:
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@wanadoo.fr>:
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-tp270... Sent from the Boost - Dev mailing list archive at Nabble.com.