Subj : Re: Can C++ local static objects be made thread safe?
To   : comp.programming.threads
From : Giancarlo Niccolai
Date : Wed Feb 02 2005 04:15 pm

Gianni Mariani wrote:

> David Schwartz wrote:
>> "Gianni Mariani" <gi2nospam@mariani.ws> wrote in message
>> news:iaudnW0LQIcam2zcRVn-ig@speakeasy.net...
> ...

>> 
>> 
>>     This isn't quite right. Another thread could see 'm_val' as true, and
>> the 'xlocal' as non-NULL and still not see the writes inside 'x'. You
>> need a memory barrier in every possible case, unfortunately. Not all
>> architectures provide a way for one thread to force another thread to see
>> something.
> 
> Just a minute - how can that be.
> 
> On the first time through, a memory barrier sync is done.  Worst case,
> you can't come out of this code normally without the construction being
> completed. Once you decide that you're locking the mutex, I assume
> barriers are looked after.  The m_val value is thread local, meaning
> each thread executed the memory barrier at least once - once the memory
> barrier is synced once, why would it need to be synced again ?  If it
> did, somthing much more serious is broken.

Please, Gianni, do not take what I am going to say as a personal matter;
Indeed, I am taking this thread as just an occasion to make a general
statement.

The fact is that you are trying to solve an unexisting problem. The solution
may be technically clever, and foundamentally right (I don't say it is,
others here more "technical" than I am have argued against it and I am not
commenting their judgment), but the -problem- is incorrect. You are not
looking in the right direction; you are looking DOWN, while you should be
looking BESIDE. 

The very heart of threading is not in the clever lock or in the finest
memory barrier; it's in the way you organize your program as a set of
parallel agents. Even if you lock well the initial static-based
constructors (which is a Wrong Thing anyhow, but let's suppose it's fine
for just a moment), this won't solve the general problem of threading
before main. Not because main() is a magical thing where all works, but
just because main() is the first place where you are in perfect control of
the control flow of the program. And perfect Control of the flow is the
prerequisite for correct parallelism. You HAVE to drop this control now and
then in parallel programs, but YOU are in control about WHEN to drop it and
WHEN to re-acquire it. Loosing this meta-control means just disaster.

So, even if constructors were built right in a MT environment, if they do
depend on each other in a pure parallel fashion, how may a generic program
ever hope to work correctly? And if there isn't any hope to make the very
generic program using randomly initialized constructors in a MT environment
to work correctly, due NOT to language missing features but to the
impossibility to manage the general parallel flow case, how can ever be
useful a thing allowing you to reach safely such an unsafe state?

A program with parallelism in its static constructor MAY work, and it MAY
take advantage from an automated constructor protection mechanism, but that
would not be the generic case anyhow; it would do only for limited
interaction between parallel agents that cannot be controlled before the
program steps in. So, how this technique, applied to the generic case, may
ever be useful?

Giancarlo.

.