Subj : Re: Can C++ local static objects be made thread safe? To : comp.programming.threads From : gniccolai Date : Mon Mar 07 2005 07:31 pm Marcin 'Qrczak' Kowalczyk wrote in message news:<87vf8oqhpu.fsf@qrnik.zagroda>... > gniccolai@yahoo.com (Giancarlo Niccolai) writes: > > > Sorry, but there's nothing in your test that resembles the class of > > problem we are discussing here. No one wants to recursively initialize > > nothing. > > > You don't listen to a proof that it can't break anything, so perhaps > you will be convinced by the impossibility of constructing an example > which would confirm your claim. Since you are arguing that *some* code > can break, one correct example is enough. I suppose we had a little *base* misunderstanding on this topic. This is my position: A well buit program (at least in the sense of POSIX threading paradigm) NEVER calls an initializer twice. A correctly built threading program MUST either: - Ensures mathematically that an object is initialized before it is used by program flow control - If this is not possible, it locks the code that can cause object initialization in a way that is consistent with its share data sets. A program failing to do one of the above is a faulty program both for the C++ standard (if the initializer is entered twice) and for the the POSIX standard (the object being initialized is a SHARED data which has not been guarded correctly by the implementor). The proposed solution (automatically lock the initializer outside the control of the calling program) can be a solution to fit the C++ requirements (or to prevent program failing those requirements), but still leaves the program as "conceptually" broken under the POSIX requirements. That's because the scope of the protection the posix aware program need to provide to an inizializer may be wider than the one provided autmatically in this way. IF the needed action was exacly that to wrap the initializer with a mutex, then the trick will do also for posix requirements, but if the needs of the application about the initialization are larger, then the action of just locking the initializer won't fix the logic. I even sustain that there are cases where the mechanisms that the implementor may use to prevent the initialization to be entered twice, combined with other shared data control that may legitimately exist, may be disturbed by this automatic locking, but that's not the core of the problem. The core is that auto-locking is superfluous, as 1) a correctly built program will already prevent what the auto-locks wished to prevent, and 2) autolock it doesn't give the certainty that a non correct program (that may have crossed the initializer twice) is fixed. That's what I mean when I say that the solution solves a non-problem. You still need to take care of the consistency of the state of your program around the position where the static initializer may be created. Of course, you may know that locking the initializer is enough for your program to be safe; in that case what have you gained with the automatic locking of the initializers? Probably, you have just spared an inline or two. A reasonable solution may also be that of turning that feature on upon request, that is, when you know your program's code flows requires JUST those locks to be safe. But putting it in by default (and what I fear, with the idea to remove the ability to turn it off in future), has no sense. Also, I advise that other kind of solutions enforce the C++ requirements (i.e. aborting the program if an initializer is entered twice from two different threads, but that's just one of the possibilities) may help the developers much better than this lock; I propose to dig deeper to enforce C++ standard in threading, because this solution, that is, blind locking, is absolutely inadequate for serious multithreading contexts. That's my position, and it never changed, although I focused now and then on different aspects of it, depending about what seemed relevant in the discussion flow. So, if you don't agree, please explain which part of my position does not hold true and what's the correct interpretation of reality, or demonstrate that it is based on false assuptions. Giancarlo. .