Thanks. That's not the case with "native" TLS support (it promises to zero out all values in released slot), but it's good to know that this is undefined for thread_specific_ptr. BTW, is it because such pattern of use is not considered interesting? For example, in our application there are "Database" objects which are created and destroyed dynamically, and each Database has a unique connection per thread, which are stored in the TLS. The connections are also stored in seperate lists, and are released when the Database is no longer in use - so the "default" behavior of the native API (both Win32 and pthreads) is OK with us. Anyway, thanks again for the info. Michael "Anthony Williams" <anthony.ajw@gmail.com> wrote in message news:874ouru5pm.fsf@dell.justsoftwaresolutions.co.uk...
"Michael Gopshtein" <mgopshtein@gmail.com> writes:
This is now undefined behaviour. If you destroy a thread_specific_ptr whilst any thread has a non-NULL value then you cannot rely on what happens subsequently with respect to any thread that tries to use that or a new thread_specific_ptr instance.
Anthony -- Author of C++ Concurrency in Action | http://www.manning.com/williams just::thread C++0x thread library | http://www.stdthread.co.uk Just Software Solutions Ltd | http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976