Ticket #7066 (closed Bugs: fixed)
Thread: An attempt to fix current_thread_tls_key static initialization order
|Reported by:||Pekka Seppänen <pekka.seppanen@…>||Owned by:||anthonyw|
|Keywords:||current_thread_tls_key set_current_thread_data current_thread_tls_init_flag||Cc:|
Currently Boost.Thread's Win32 TLS implementation uses a static variable (thread::current_thread_tls_key) that is not defined at a function scope.
This has a certain shortcoming: As initilization order of global static variables is not predictable, it may happen that thread::current_thread_tls_key is used (via thread::set_current_thread_data()) before it is actually initialized by compiler (or the underlaying OS, to be precise). (An example: class that uses thread_specific_ptr and is not heap allocated.)
Potentially any prior versions to Boost 1.50.0 are also affected, as 1.50.0 merely changed the initial value from a zero to a non-zero value.
A proposed solution is to move thread::current_thread_tls_key inside a function scope (inside a helper function that sole purpose is to return reference to that variable). This ensures that current_thread_tls_key is initiliazed properly before it's used for the first time. As thread::set_current_thread_data() uses a static current_thread_tls_init_flag Boost.Once flag that is currently initialized at a global scope, move that flag too inside a function scope.
A patch that implements proposed solution is attached. Unfortunaly, currently no test case exists (not sure if one is too easy to be made; At least on MSVC9 global static variables are initialized before the program's entry point inside a simple loop).
Changed 20 months ago by Pekka Seppänen <pekka.seppanen@…>
- attachment boost_1_50_0_current_thread_tls_key.patch added
- Status changed from new to closed
- Resolution set to fixed