|
|
Threads-Devel : |
From: Anthony Williams (anthony_at_[hidden])
Date: 2008-03-14 10:05:31
Quoting Daniel <danne_esset_at_[hidden]>:
> I hava a question regarding the implementation of
> set_current_thread_data which looks like belowe:
>
> void set_current_thread_data(detail::thread_data_base* new_data)
> {
>
> boost::call_once(current_thread_tls_init_flag,create_current_thread_tls_key);
> BOOST_VERIFY(TlsSetValue(current_thread_tls_key,new_data));
> }
>
> Why do not the thread_specific_ptr ctor call
> create_current_thread_tls_key? so the call_once can be removed?
This call is not directly related to thread_specific_ptr. The "Current
Thread Data" in question is the data block for the current thread that
contains *all* the thread_specific_ptr data for the current thread,
the interruption flags, the thread handle, the thread ID, etc. This
function is called when a thread is started, or when a boost.thread
function that needs the data block is first called from an external
thread (e.g. thread_specific_ptr functions). This ensures that only
one win32 TLS slot is used for all the boost stuff, in order to avoid
overuse on systems with limited TLS slots (e.g. WinCE).
call_once is not especially slow: the cost of call_once with an
already-completed function is a single load, so this shouldn't be the
slow part.
> The reason for asking is that I saw a significant performance
> increase while moving from boost::thread_specific_ptr to a custom
> wrapper around the win32 TLS functions (TlsAlloc ..) for my
> experimental implementation of hazard pointers. The test involved
> equal number of thread_specific_ptr::get() and popping from a lock
> free stack (including calling delete).
If you have a lot of thread_specific_ptrs then there will be a
performance hit. The current implementation uses a singly-linked list
of key/value pairs, which must be searched in order to get/set the
value for a given key. It was the "simplest thing that could possibly
work", and is not optimized for performance. I should probably change
it to some form of lookup table --- even a std::map is probably better
if you have many thread_specific_ptrs.
Anthony
-- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL