Subj : Re: Can C++ local static objects be made thread safe? To : comp.programming.threads From : gniccolai Date : Mon Mar 07 2005 06:52 pm "David Schwartz" wrote in message news:... > "Giancarlo Niccolai" wrote in message > news:95e4efda.0503070402.2dae4316@posting.google.com... > > > 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. > > Surely you agree that it is necessary to prevent concurrent access to > initializers *somehow*. Of course; and we agree also on the fact that POSIX says that it is the toplevel logic (i.e. the programmer) that must explicitly avoid concurrent access to initializers (or any other code that requires to run in a non-concurrent context, like code accessing shared data); and we probably also agree on the fact that this is a sage behavior for the general case. However, a possible *somehow* to prevent concurrent access to initializers, IMHO, may be to cleanly abort the program (i.e. segfault it) with a waring. This is easy to achieve; we have 64 bits atomic thing; the first half will be for "being in transit" and the second half will be for "operation complete" (you can do it even with two bits). If a thread enters the initializer, the transit flag is atomically set, and when it exit, it sets the complete flag. If another thread enters the check-area when the initializer is complete, it just retreives the value, but if it approaches the initializer when transit is on but complete is off, bang, the application is halted with a consistent error message. That fits the C++ standard (the constructor is not allowed to be called twice) and the POSIX standard (a failing application just crash, with the addition that the failing logic and program behavior is exposed). This is as if we have an implicit assertion that cannot be turned off with NDEBUG. I can grasp also other solution that may not require locks, but I must elaborate them a little more before stating them. ATM, aborting a probram that has done this fault seems the most reasonable solution to me. > > > 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. > > Which is entirely reasonable, assuming we're not talking about code that > conforms to POSIX. Well, IMHO POSIX is the best solution to the threading problem around, when it comes to a "generic" soltuion; and is not even the only one that would be broken by this way of thinking: Also Win threads were willing to do as posix (they failed because the lack of some important semantics and concepts that posix has, but the intention was that of having fine control at toplevel logic, as POISX). Just, they don't have explicit "standard papers". Those two players are just too big to dismiss them as "just two implementations". *Please* know that I am not saying that you say that those are just two implementation: I am referring to ABI business; before to mangle with a so delicate thing, one should at least ask himself why other smart ppl has come to a different conclusion before. > > > 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]" > > I just hope this isn't indicative of their general level of > understanding of threads. Hoping won't fix things ;-) I'm afraid that this IS indicative of their general level of understanding, and not just about threading: yes I always say that threading IS DIFFERENT than all the other IT contexts, but knowing your own limits is the first step to knowledge, and just pushing the close/wontfix icon when two ppl say that you are breaking a standard says a lot about how this kind of problems are dealt. [However, I am probably not in the best position to preach this thing; it has been THIS newsgroup that reshaped my knowledge about my limits... Before being here I just tought I knew enough to understand everything in the computing field, now I know that must approach each new problem with respect and modesty. So, if threading did this to me, I suppose that it must be hard to grasp for outsiders... someone called me "religious" about this topic, but indeed I am just mathematic about this: threading to Von Neumann abstraction is like non-euclidean geometry to the 5 geometry postulates. It just changes everything, and sometimes it is hard to make ppl understand it] Gian. .