Subj : Re: Can C++ local static objects be made thread safe?
To   : comp.programming.threads
From : David Schwartz
Date : Tue Mar 08 2005 12:58 am


"Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl> wrote in message 
news:87is421s0q.fsf@qrnik.zagroda...

> gniccolai@yahoo.com (Giancarlo Niccolai) writes:

>> 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.
>
> Why don't you say the same about pthread_once, that it should only
> provide checking for being entered the first time, and the programmer
> should ensure that it's not entered concurrently?

    Because pthread_once is specifically defined to be used in the case 
where the programmer does know that it will be used concurrently.

>> 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).
>
> But perhaps not for a hypothetical POSIX/C++, if it specifies that
> lazy initialization of static locals is MT-safe, just like pthread_once
> in POSIX/C.

    No hypothetical POSIX/C++ would ever do this because it is 100% 
anithethetical to the locking model POSIX chose. A hypothetical 
multi-threaded C++ standard not including POSIX might.

> Since standards are better based on existing practice than created out
> of the blue, and in this case making the change before it's standarized
> is conforming because one of the behaviors causes a strict superset of
> programs of the other to be valid, they just created the practice.

    That's perfectly fine. I have no problem with that. What I have a 
problem with is disabling an optimization when the programmer specifically 
stated that the optimization is allowed. No other GCC option works this way.

>> 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.
>
> In this case the locking is redundant, but not wrong.

    Correct, it's a 100% pessimization in the POSIX case.

>> 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.
>
> If the data is mutable - yes, buf if it's immutable then
> synchronization of initialization is enough.

    The point is, only the programmer knows this.

    DS

.