Hello, can I create an static thread specific pointer for class which will initalized by different threads? struct X { static thread_specific_ptr< U > tss_ptr_; }; in some threads: X::tss_ptr_.reset( new U); And for each thread X::tss_ptr_ will point to a different object in the freestore? Oliver
k-oli@gmx.de writes:
can I create an static thread specific pointer for class which will initalized by different threads?
struct X { static thread_specific_ptr< U > tss_ptr_; };
in some threads:
X::tss_ptr_.reset( new U);
And for each thread X::tss_ptr_ will point to a different object in the freestore?
Yes. That's exactly the intended usage. Only the thread that calls reset() can access the object passed in. 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
Anthony Williams wrote:
Yes. That's exactly the intended usage. Only the thread that calls reset() can access the object passed in.
Does this mean you have solved the initialization problem for local statics? i.e. you made this thread-safe for every compiler? (I remeber a very nasty bug in spirit because of the cited pattern.) Roland -- _________________________________________ _ _ | Roland Schwarz |_)(_ | aka. speedsnail | \__) | mailto:roland.schwarz@chello.at ________| http://www.blackspace.at
Roland Schwarz wrote:
Does this mean you have solved the initialization problem for local statics? i.e. you made this thread-safe for every compiler?
Sorry, the shown usage pattern of course is not necessarily usgae as a local static. Nevertheless the question arises if the usage as a local static is thread safe. I.e. in the example shown struct X should live as a global variable in general. (I.e. if there are no provisions in thread_specific_ptr that make it safe.) -- _________________________________________ _ _ | Roland Schwarz |_)(_ | aka. speedsnail | \__) | mailto:roland.schwarz@chello.at ________| http://www.blackspace.at
Roland Schwarz <roland.schwarz@chello.at> writes:
Roland Schwarz wrote:
Does this mean you have solved the initialization problem for local statics? i.e. you made this thread-safe for every compiler?
Sorry, the shown usage pattern of course is not necessarily usgae as a local static.
Nevertheless the question arises if the usage as a local static is thread safe. I.e. in the example shown struct X should live as a global variable in general. (I.e. if there are no provisions in thread_specific_ptr that make it safe.)
No, I haven't solved it. Local statics are still a problem. The question was about a class static, which is global, and thus safe. 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
Andrey Semashev wrote:
Anthony Williams wrote:
The question was about a class static, which is global, and thus safe.
Is it? If my reading of 9.4.2/7 and 3.6.2/3 is correct, static data members are permitted to be dynamically initialized after entering "main".
I think you are right. Pretty much only global static PODs are (must be?) statically initialized. const local PODs can also be statically initialized, if I remember correctly. In some work where I was helping from afar (read: not my fault!), we had to be sure to explicitly poke all the tss_ptrs when starting the program. If not, we had crashes when running in multiple threads for this reason. It was on a non-mainstream C++ platform though so I'm sure the people who wrote that compiler interpreted the standard as was convenient for them! This was in a much older Boost version though. My very humble suggestion is to use a call_once based singleton or initialize everything before starting any threads. -- Sohail Somani http://uint32t.blogspot.com
Roland Schwarz wrote:
Anthony Williams wrote:
Yes. That's exactly the intended usage. Only the thread that calls reset() can access the object passed in.
Does this mean you have solved the initialization problem for local statics? i.e. you made this thread-safe for every compiler?
I think any time you see a naked local static, you've gotta think bug because the only portable way to solve this problem is to use boost::call_once, afaik anyway. -- Sohail Somani http://uint32t.blogspot.com
Roland Schwarz wrote:
Does this mean you have solved the initialization problem for local statics? i.e. you made this thread-safe for every compiler?
(I remeber a very nasty bug in spirit because of the cited pattern.)
This was fixed in Spirit by solving the said problem. You can find the solution here: <boost/spirit/home/classic/core/non_terminal/impl/static.hpp> http://tinyurl.com/byve27 with usage illustrated here, around line 238 (look for get_definition_static_data_tag): <boost/spirit/home/classic/core/non_terminal/impl/grammar.ipp> http://tinyurl.com/cbnuca Admittedly it can be cumbersome, but it works. A performance hit has been reported for repeatedly callling call_once, that can be solved with double-checked locking. This is not implemented in the repository version. Cheers, João
participants (6)
-
Andrey Semashev -
Anthony Williams -
João Abecasis -
k-oli＠gmx.de -
Roland Schwarz -
Sohail Somani