Subj : Re: Can C++ local static objects be made thread safe? To : comp.programming.threads From : gniccolai Date : Sat Feb 19 2005 03:04 pm Alexander Terekhov wrote in message news:<4217611A.44A9AED5@web.de>... > Marcin 'Qrczak' Kowalczyk wrote: > [...] > > It can be turned off, but not because it might not work (it doesn't > > break correct programs): "Most users should leave this alone, > > but embedded programmers may want to disable this by specifying > > -fno-threadsafe-statics for a small savings in code size." > > It saves not only code size. Useless syncronization is expensive > and shall be avoided as a matter of principle (apart from its > negative impact on performance). That's why making all static > locals synchronized "just in case" is totally brain-dead. They > should have provided a pragma, attribute, keyword, or something > like that to control it on per instance bases. > > regards, > alexander. I CANNOT BELIVE IT. GCC 4.0 is going to lock initializers on THIS C++ ABI CLOSURE: http://www.codesourcery.com/cxx-abi/cxx-closed.html#G4 ---- Since there has been no further feedback from HP on the more complicated proposal above, and the current HP attendees do not think it necessary, this issue will be closed. ---- Actually, they are doing it (locking the initializer) because the lack of interest in the matter, and probably because of the lack of specific skills on multithreading, and the point that they have reached was absolutely discussed with *negligence*, at least. And they didn't heard the Open Group... Their *seemingly* only authoritative source is "what HP compiler is doing now" (sic). Alexander, do you think that it's worth to open a new thread to discuss this question seriously and post our thoughts to GCC steering committee and C++ ABI or should we just surrender to this negligence? Gian. P.s. I can accept the fact that C++ says that a static initializer must not be crossed more than once... but 1) it does not says a word about multithreading, and what to do in that case, so multithreading is "not covered" by this rule, or if covered with wordings as "for the whole process", we should rethink them and 2) there may be more intelligent ways to do enforce this on MT if we think about it. .