"Michael Gopshtein"
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.
Allowing this is a potential for memory leaks. pthread_key_delete does not run the destructor function, so if you have dynamically allocated memory (or other resource) referenced by the key value you have a leak. By its very nature, thread_specific_ptr has dynamically allocated memory for each key value, so it is important to ensure that it is correctly deleted in each thread. 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