ee7
Subj : Re: Can C++ local static objects be made thread safe?
To   : comp.programming.threads
From : gniccolai
Date : Wed Feb 09 2005 05:23 pm

Marcin 'Qrczak' Kowalczyk <qrczak@knm.org.pl> wrote in message news:<87oeeyowhj.fsf@qrnik.zagroda>...
> Giancarlo Niccolai <searchforme@ingoogle.com> writes:
> 
> > I don't want to have thousand of mutexes I can't control around,
> > especially when I don't need them.
> 
> Why?
> 
> Then don't use static locals with dynamic initialization. They are
> supposed to be initialized on the first time they are used, and in
> a multithreaded environment the correct implementation of "the first
> time it is used" needs something like pthread_once - a guard variable
> is thread-unsafe.
> 
> > And I can write code that would be broken also by a-mutex-per-class
> > thing.
> 
> It's a pthread_once_t per a contiguous block of static locals. It does
> not break, unless the code is already broken with a guard variable
> semantics.
> 
> > And... btw... have you thought about how to... INITIALIZE EACH MUTEX
> > IN A THREAD-SAFE WAY?
> 
> As with pthread_once, with PTHREAD_ONCE_INIT.

Ok for pthread_once to initialize the mutex; but if initializing
unneeded mutexes is not a problem for you, I can assure that is a
problem for me (and for many others).

I hope that this explain why mutex applied to "code section" are
basically wrong: mutex are meant to guard data access on a data set. A
data set guarded by a mutex needs NOT to coincide with a whole class.
I may i.e. legally create a data set merging PART of a class data and
another data set with other PARTS of the same class data. This code
won't be made safe by locking its initializers.

LOCKING is to lock data, NOT PROCESSING. By forcing mutexes to guard
the process, and not the data sets (because the compiler has no idea
about the data sets I am using), you are misusing mutexes. And
misusing things brings bad luck... (and no, a "class" is not a data
set. It may be, if the programmer wish so, but the compiler has no
hint, in C and C++, about the fact that some data set is being defined
and used by the programmer).


> 
> > 1) solves an unexisting problem
> > 2) can break correct programs
> > 3) makes an ugly thing (static initialization) just worse.
> 
> All three claims are false. It just turns the semantics of
> initialization of static locals from MT-unsafe to MT-safe.

Ok. Demonstrate it. Demonstrating it means: prove mathematically that
your statement is true (and mine are false) under all possible ever
existing conditions.

1) Demonstrate that the thing is an EXISTING problem. That is,
demonstrate that the average threaded program does static
initialization wrong (because the average programmer needs the help of
the compiler).
2) demonstrate that using a mutex across any possible data set (and
any possible function call) does not break any possible program.
3) (well, this is a matter of taste, but however you may try to
demonstrate that complex applications are simpler/more
robust/safer/nicer if using static initializers to build singletons).

I proved that your statements are false, unless applied to a
restricted set of the possible cases. You CLAIM I am wrong, (and so,
that mutexing makes every ST static initializer safe in MT, and that
this mutexing never breaks working  MT code, which uses different
synchronization methods) but produce no proof. You just say "it is
this way, 'cause it seems so fine".

Even if you "just know you are right", and even if no-one can write
some that can convince you of the contrary, unless you can DEMONSTRATE
that you are right, you have to just leave compilers alone. Or at
least, make your desired behavior optional.

Bests,
Giancarlo Niccolai.

.

0