Subj : Re: Can C++ local static objects be made thread safe?
To   : comp.programming.threads
From : gniccolai
Date : Wed Feb 16 2005 07:08 am

Marcin 'Qrczak' Kowalczyk <qrczak@knm.org.pl> wrote in message news:<87psz0j1w8.fsf@qrnik.zagroda>...
> gniccolai@yahoo.com (Giancarlo Niccolai) writes:
> 
> > Someone proposed to have a mutex to lock a static initializer
> > constructor call (not pthread_once like Marcin only lately suggested,
> > which brings other problems that I don't want to discuss now);
> 
> It is equivalent (modulo cancellation, i.e. the mutex should be
> released when the initializer is cancelled).

No, it is not equivalent (thanks god), as pthread_once does not need
to use a mutex, and usually (in well built implementations) it does
not. But there are other problems, that I won't discuss with you.

> > acquire_recursive_mutex_used_in_cls_constructor()
> > the_safe_initializer()
> > cls.something = change()
> > release_recursive_mutex_used_in_cls_constructor()
> 
> It may not reenter the_safe_initializer. Reentering a static local
> initializer before its previous run has finished is forbidden by the
> C++ standard.

There is no reason why I may not lock a mutex before entering a
function (constructor or anything) that uses it as well (provided it
is reentrant). Show me a thing in which it is said this isn't the
case. And where C++ says that I cannot use a mutex to lock an
initializer, or where Posix says that I cannot use a mutex around a
class constructor.

The above pattern usage is correct, under any standard, and an
automated mutex locking done under the nose of the developer would
break it. That's all.

> 
> You will not find a code which is broken by this change because it
> cannot exist.
> 
> > Also, someone sustained that a scheme like the one in
> > the_safe_initializer() is able to secure any single thread code
> > against improper use of concurrency;
> 
> I don't believe anybody has claimed this.

Yes, they did. Do a search on the message bodies.

Gian.

.