Subj : Re: Can C++ local static objects be made thread safe? To : comp.programming.threads From : gniccolai Date : Fri Mar 04 2005 12:49 pm "David Schwartz" wrote in message news:... > "Giancarlo Niccolai" wrote in message > news:cvklr4$sgl$1@fata.cs.interbusiness.it... > > > I just protested for this thing. > > > > I also wrote to ABI C++. > > 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. And this is why G++ has put that in by default, with the advertisement not to disable this feature (antichamber of a future removal). 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..."). If ABI is so influent then it should be more careful in what it does, and prevent from "suggesting" standard because the lack of interest in them. > 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. > > 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. 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. > 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? 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. Bests, Giancarlo Niccolai. .