Subj : Re: Can C++ local static objects be made thread safe? To : comp.programming.threads From : David Schwartz Date : Fri Mar 04 2005 01:02 pm "Giancarlo Niccolai" wrote in message news:95e4efda.0503041249.8671c76@posting.google.com... > "David Schwartz" wrote in message > news:... >> There's nothing wrong with the C++ ABI. As I understand it, it leaves >> space for a flag to indicate whether an object has been initialized or >> not. > Maybe (I underline maybe) they LEAVE this space, but they firmly > suggest to do otherwise. That's perfectly appropriate. C++ is not POSIX. > And this is why G++ has put that in by > default, with the advertisement not to disable this feature > (antichamber of a future removal). That is the problem, that they put in the lock when the user specifically states that he has already locked all shared data. > Also, the thing is so true that the > guys at GCC have put that autolock in for the ABI closure AND closed > the bug request +/- for the same reason ("ABI said it..."). That's their mistake, not the ABI's. >> It doesn't *require* locks during initialization. If it did, the G++ >> option >> to avoid them would violate the standard. > 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. >> Why? The pthreads standard is absolutely clear and not in error. The >> C++ >> ABI is absolute clear and not in error. > IMHO, they are. PTHREAD is explicit about locking what's shared, and > other standards probably not, but that suggestion may cause trouble > wichever standard you use. I.e. with windows threading it's probably > worse. That's not the C++ ABI's fault. > 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. >> which doesn't turn the locking off when the programmer specifically >> indicates that he has locked all cases where data may be shared (implied >> by >> '-pthreads'). > But there's nothing in the ABI standard nor in the PTHREAD standard > suggesting this; so, following your same reasoning, doing this would > break one standard... or both? Huh?! The pthreads standard requires locking when data may be read in one thread when it is or may be modified in another thread. This permits the optimization of omitting the lock. G++ supports specifically this optimization for specifically this case, it just fails to enable it. In other words, the error is simply that G++ fails to realize that -pthreads implies -fno-threadsafe-initializers. This is a pure G++ error. In every other case, the default is to allow the optimization the restrictions in the standard make possible. > 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. DS .