Automatic locking for C++ local static initialization

[Christophe de Dinechin]

Jim,


Violent agreement there. I carefully selected the words "has an impact on a
threading implementation" to mean what you said: that the Standard does not tell
you what to do, but that the set of reasonable extensions is limited. Note that
this is all "undefined behavior" anyway. But my opinion is that it does not
encourage executing the same constructor twice.


Christophe

Jim Dehnert wrote:
> 
> > From: Christophe de Dinechin <ddd at cup.hp.com>
> >
> > The C++ Standard says so: you are not allowed to enter the same constructor
> > twice. To me, this is one of the rare statements in the Standard that has an
> > impact on a threading implementation.
> 
> Without taking a position on the overall question, I think it's
> important to comment on this statement.  The Standard does not
> contemplate threading, period.  Some threading issues might be impacted
> by "reasonable" extensions of what is stated, such as the one you cite,
> but that was not the intent of the Standard, and should not be
> interpreted that way.  The Standard describes a sequential language.
> If it were extended to explicitly encompass threading, many issues
> would need to be dealt with, and in that context, many of them might
> not come out as pure "extensions" of the current language.  I think,
> for instance, that an equally reasonable extension to this case would
> be simply to forbid (make undefined) multiple threads from entering a
> scope with local statics needing construction at the same time.
> 
> This is similar to the issues involved in global object destruction
> when a DSO is unloaded early.  The Standard, which doesn't contemplate
> DSOs, specifies a destructor order that isn't practical if the DSO goes
> away early.  So we do something "reasonable," albeit contrary to the
> Standard.
> 
> The threading issues are the same.  We don't have guidance from the
> Standard -- while we should certainly consider its principles as
> guidance, we shouldn't consider its rules as determining choices in
> areas to which they weren't intended to apply.
> 
> Jim
> 
> -           Jim Dehnert         dehnert at sgi.com
>                                 (650)933-4272