Bugzilla from anthony.ajw@gmail.com wrote:
Andrey Semashev <andrey.semashev@gmail.com> writes:
On 01/11/2010 05:22 PM, Stefan Strasser wrote:
even though I understand the need for it now, it still seems odd that we use a std::map to simply access a value in another memory segment.
have you thought about dynamically allocating an index into a (thread-specific) vector instead of a key based on the thread_specific_ptr's address? IIUC that would allow constant-time access in all cases.
Yes, that's what I did in my patch in ticket #2361. One inconvenience with that approach is to restrain the size of the vector if thread_specific_ptrs are constantly created/destroyed. I did not solve it in my patch but it should be quite doable.
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.
It is possible that an alternative scheme (such as using a sorted vector as a map) might yield something that is more reasonable on both fronts.
Anthony
I would provide the thread_specific_ptr interface at several levels: * 1st: using the specific 3pp/OS libraries interface (the number of instances are limited by the 3pp/OS. The cost of this depends on the 3pp, but usually is constant. The key need usualy less that 16bits. * 2nd: the library could use a fixed size array allowing to extend the number of TSS instances. The size of this direct access could be not too big (256). The cost of this is the cost of 1st + one indirection + constant access to the array. The key need usually less that 16bits. * 3rd: the library could use a dynamic size map as now allowing to avoid limits. The cost of this is the cost of 1st + one indirection + log(N) access to the map. If the key is the address the key spends sizeof(void*). The 1st level should be reserved to generic libraries that are could be used by any application and with a high frequency usage of the get function. I'm thinking for example to the current transaction on a transaction based application, the current log, ... We can also add another that could try on best level starting from a given one: try the 1st level, if no 3pp/OS key is available it continue with the 2nd level, and if not available continue with the 3rd level. I'm sure we could store these keys on a 32bits for 32 bits machines. We need just two bits to indicate the kind of key. 0 1st level 1 2nd level 2 3rd level Just my 2cts 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.