Re: [Boost-users] [thread] thread_specific_ptr is not initializedwith NULL

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" wrote in message news:874ouru5pm.fsf@dell.justsoftwaresolutions.co.uk...

"Michael Gopshtein" 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