Subj : Re: Can C++ local static objects be made thread safe? To : comp.programming.threads From : gniccolai Date : Sat Feb 19 2005 02:35 pm Marcin 'Qrczak' Kowalczyk wrote in message news:<87hdk8emfb.fsf@qrnik.zagroda>... > gniccolai@yahoo.com (Giancarlo Niccolai) writes: > > > Then the problem remain the same as with the mutexes; pthread_once > > just atomically initializes some internal mutex, or other blocking > > thing, but semantically doesn't move our problem of deadlocking code > > that has been safe by itself before... > > The point is that it has *not* been safe before. Recursive > initialization of static locals has never been correct C++. > > -------- > bool done = false; > > void test(); > > class C { > public: > C() { > if (!done) { > done = true; > test(); > } > } > }; > > void test() { > static C x; > } > > int main(void) { > test(); > } Sorry, but there's nothing in your test that resembles the class of problem we are discussing here. No one wants to recursively initialize nothing. You are away 100 miles from the problem, I'm afraid. What is at stake here is that you may protect the access to shared data, be this protection needed in an initialization function body or in any other part of the code. If the compiler protects the ACT of the initialization, then it puts at risk any DATA PROTECTION that the code may need to perform inside the initialization (and I underline NEED). This is the thing that you keep not understanding. Again, and once and for all, locking, pthread_oncing, or doing anything at all about multithreading to static initializer is: 1) useless 2) unefficient 3) theoretically incorrect 4) practically dangerous 5) (using Terekov wording) Brain Dead. That's it, and since you've been threading *apparently* by something of three months (by the posting dates and the questions you posted), and you stay away from C++ as far as you can (from your words), you should probably try to make an effort understanding why it is this way, if my words were not enough to explain it, and if Therekov comments are not enough, rather to blindly belive that some complier guys did the rigth things. Other example of ppl (probably smarter than you and me togheter) that made threading the wrong way: - Microsoft: Windows threading SDK prior to Windows 2000. - Sun microsystem: Java first version of threading based on the object monitor. - Python VM/garbage collecting. Also, Boost and Common C ppl, really smart persons, have been trying to make something out of it for some 3 years now, maybe more. Most PPL just rush in reading something here and there and saying, "Hey, I am a smart one, I just have to lock here and signal there and I'll be multithreading as I always programmed." I say this because I was one of them, and I see you are now. Obvously, the ppl that is willing to add this crap to a compiler is of this kind too. Well, know the news? IT'S NOT JUST THAT. You can learn it the easy or the hard way, it's up to you; just I don't want this thing to blow my programs. Gian. .