Subj : Re: Can C++ local static objects be made thread safe?
To   : comp.programming.threads
From : Marcin 'Qrczak' Kowalczyk
Date : Tue Mar 08 2005 09:05 am

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?

> 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.

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 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.

> 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,

There are not. Please show one.

> 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.

BTW, while global mutable state is often a poor design, global
immutable complex structures are perfectly fine.

> 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.

The part about locking of static local initializers causing some
correct programs to break. I've already proven that they can't break
anything.

Other than that, they are subjective judgements about the intended
usage of static locals in MT code, which can't be said to be correct
or incorrect. Of course this applies to both sides of the discussion.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

.