Subj : Re: Can C++ local static objects be made thread safe? To : comp.programming.threads From : Marcin 'Qrczak' Kowalczyk Date : Sat Feb 05 2005 01:31 am Giancarlo Niccolai writes: >> Please show how it's broken when thread local static objects are >> initialized in a thread-aware way, and at the same time it works >> when they are initialized using an traditional guard variable. > > Thread-aware way do not mean locked; it may require locking it may > not require it, it may suffice or not. The BAD thing is that THIS > kind of blind-locking may get in the way of the CORRECT way to > secure your code, preventing you from really doing so. I am sorry, > but if you don't get this, I cannot absolutely do nothing more to > help you. I'm saying that you are wrong, and this kind of locking doesn't get in the way - sometimes it helps, sometimes it doesn't help, but it never makes things worse except efficiency. I will happily admit my error if there is indeed some non-perverse code which is being broken by this semantics of local static initialization. You have been unable to show sketch such code, and I can't imagine how it may look, so I claim that it doesn't exist until it's shown otherwise. > Your correct ST code may need some deeper function that needs to be > changed in MT for any reason. If this change breaks the thread-aware semantics of initialization, it will also break with the traditional semantics of a guard variable. Instead of a deadlock you will have concurrent initialization before the first initialization has finished - undefined behavior. > I am not trying to demonstrate that all the code will be broken with this > addition, I am just telling you that this addition cannot make every > possible ST code that may be initialized that way threadsafe in MT context, I agree with this, > and that some correct MT code may get broken. but not with this. Please show such code. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/ .