id,summary,reporter,owner,description,type,status,milestone,component,version,severity,resolution,keywords,cc
7066,Thread: An attempt to fix current_thread_tls_key static initialization order,Pekka Seppänen <pekka.seppanen@…>,Anthony Williams,"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).
",Bugs,closed,Boost 1.51.0,thread,Boost 1.50.0,Problem,fixed,current_thread_tls_key set_current_thread_data current_thread_tls_init_flag,