Subj : Re: Can C++ local static objects be made thread safe?
To   : comp.programming.threads
From : Giancarlo Niccolai
Date : Wed Mar 09 2005 10:07 pm

Marcin 'Qrczak' Kowalczyk wrote:

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

I, and others, have already replied to you on this topic. Go to read the
replies.
Also, the rationale in POSIX is explicit. Read it.

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

Are you really sure that a thing that is plainly declared as brain-dead by
some of the most authoritative persons out there (I am not counting myself
in) is worth entering the standard just because a lot of ppl uses it
(badly)?

Boys, I had the code of MPLAYER-PLUGIN in my hands today, and I just
screamed. It's a fair on what you should not be doing with pthreads... that
code just yell for vengance. I could use it in my classroom as an example
on what not to do. However, often it works, just... it is breaking my
application (well, I am not the only one reporting that the thing is
fragile, at least). Are you THAT sure that standards must come from generic
practice, or just from what seems to make sense to persons being experts in
OTHER fields (i.e. compiler writers thinking they know threading?)

Or said more directly: how long have you been coding in C++? How long have
you been doing threads? how many market-level applications have you been
writing in both the fields? I know that sometimes it is nice to think that
"after all, being smart is better than being experienced", but do you
really think you are THAT smart to be able to say what the standard should
be above ppl that gave their names to algorithms or wrote books on the
topics here? Or shouldn't you be paying a little attention on what ppl that
have a little more experience than you in those fields have been telling to
you for no less than 100 messages?

And why do I insist replying you instead of just ignoring you? Simple:
because a compiler writer with no experience on threading may stumble on
your messages and find your argumentations appealing, without being able to
understand that they are wrong. Or a newby may find your messages, and find
them appealing... and so on. And I have a sense of responsibility towards
those persons.

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

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

I don't agree: there's synchronized things that are good if you encapsulate
them, and others that get worse. It depends: good design does not mean
encapsulation, nor encapsulation is good design by default (there's even a
non-small thinking party that sustains that OOP is evil; as I have been a
C++ developers for about 15 years now, I am not one of them).

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

No, you did't (no mathematical, nor logical, demonstration posted here);
also, I provided a sample and you failed to demonstrate that it was not
valid. However, that's just a marginal aspect of the problem, so if that is
the only part that you claim being wrong in my position, there's no point
to go on.

Gian.

.