Subj : Re: Can C++ local static objects be made thread safe? To : comp.programming.threads From : gniccolai Date : Mon Mar 07 2005 04:02 am "David Schwartz" wrote in message news:... > "Giancarlo Niccolai" wrote in message > news:95e4efda.0503041249.8671c76@posting.google.com... > > > There are tons of options that violate the standards, depending on the > > mood and the likes of the compiler writers and users, so the point > > shows nothing. > > It shows that ommiting the locks would not break the ABI. > IMHO, it just show that the compiler writers don't care about breaking it, or don't know what they are doing... But now I found another problem, We have two conflicting solutions: C-14 Local-scope dynamic constructors data closed all 000309 000511 Resolution: The size of the guard variable is 64 bits. The low-order byte shall contains a boolean initialization flag. This resolution does NOT implies that the flag is used ALWAS, nor HOW it must be used. It just says it must be there, then the implementors are free to do as they like. and the next... > > > And still worse, instead of suggesting that it would be better to > > provide means to prevent concurrent initializer calls to happen (which > > I have a couple not requiring locks in mind), they specifically > > require the impementation to use their API (so says the closure), that > > is, locking it by good. > > I don't see that. here it is: G-4 Dynamic init of local static objects and multithreading call closed SCO 990607 001109 Resolution: The ABI will specify an 8-byte guard variable, with one byte used for the initialization flag, and the others available for use by a threading package for locking. ABI routines are specified for acquiring and releasing the lock. See ABI section 3.3.2. Now, this problem is of a comparable class of the problem at C-14, but this time the ABI specifies the ROUTINES that must be used to solve the problem. Now, probably it doesn't explicitly say that this locking MUST always be enforced by the compiler, but if you read the relative summary (which is the premise to resolution) you understand that "to stick with C++ standard" it is NECESSARY to prevent concurrent access to initializers by the means of their resolution. That is, on ABI opinion, NOT using their routines in MT does not break ABI; it breaks C++. That's my reading, at least, and ABI is seemingly doing all to encourage this reading. > > IMHO, that closure is just wrong, no matter which threading model was > > aimed to fix. > > > > - If not general, it must be specified where it applies, and not left > > to the goodwill of the compiler writers (that, we see, is lacky). > > > > - If general, locking cannot be used as a mean to achive the goal they > > wish to accomplish. > > Regardless, that's not in remotely the same league as the G++ issue. The > G++ issue is an absolutely fundamental misunderstanding of POSIX. Read the > responses to my bug report. The analogy of thread-safe user-coded > initializers to a thread-safe errno or malloc shows this dramatically. > On this topic we 100% agree. The topic has been treated with "lightweightedness" by ABI, as clearer statements are in order, but I can't say they are wrong, at least if you just take their resolution wording with litteral understanding. But it has been treated with just complete ignorance (and supponence) by the G++ guys; these are the most extensive replies you got: ------- Additional Comment #1 From Andrew Pinski 2005-02-20 00:52 [reply] ------- Note -fthreadsafe-statics, never made it into the FSF's 3.4.x, only 4.0.0. Also note this is required by the C++ ABI. [This demonstrates that they have done it because they had the same reading of the ABI resolution I have illustrated] ------- Additional Comment #2 From Andrew Pinski 2005-02-20 01:01 [reply] ------- Actually this code was added because well it is hard to deal with mutexies in these cases. [This demonstrates, well, ignorance of the topic]. ----------------------------------------------------- But, the thing about ERRNO and MALLOC has been said NOT by G++ developers, but by Marcin Kowalsky (a poster here) that as soon as he read about you posting the bug file, run to back up the poor G++ developers and help their reasons. You've been talking mostly with him, as Pinski seem to be the only G++ developer that replied and he just said "I don't care, I am right, ABI says it, so take it and hit the road [bug close/wontfix]" Gian. .