[cpp-threads] static locals

[Alexander Terekhov]

On 6/1/05, Andrei Alexandrescu <andrei at metalanguage.com> wrote:
[...]
> 1. There's a clear distinction between statically initialized static
> data and dynamically initialized static data.
> 
> 2. In the case of dynamically-initialized static data, the expression
> that initializes is guaranteed to be executed at runtime before any
> function in the static data's module is called. 

My reading of 6.7/4 is that "early initialization" means "early 
zero-initialization" (see 6.7/4's first statement), not "early 
dynamic initialization". Early zero-initialization and 
initialization with a constant expression (collectively called 
static initialization) aside for a moment, dynamic initialization 
occurs "the first time control passes through its declaration". 

And "if control reenters the declaration ([e.g.] recursively) 
while the object is being initialized, the behavior is undefined." 
(That covers MT races quite well.)

"static(synchronized) bool dummy = false" and alike can be 
required to issue diagnostic message because static(synchronized) 
makes sense only for dynamic initialization (of local objects 
with static storage), not static initialization. Synchronized 
dynamic initialization of local objects with static storage 
duration (i.e. well-formed static(synchronized) stuff) oughtta
have the same msync semantics as pthread_once() and 
"once<T>::operator()(function, args)" invocations -- both are 
meant to be side effects imposing inter-thread ordering (see 
proposed XBD 4.10 patch).

> Of course, a compiler could fool you if you could never tell.

"As if", of course.

> 
> Given these facts, I think it's safe to posit that
> dynamically-initialized static locals are *always* protected (in MT
> builds). As Alexander said, if someone doesn't want that, they can use
> the bool inited = false; to avoid the overhead.

That's what Peter said. I don't like it.

> 
> I feel I'm missing something though. What is that?

Likewise. ;-)

regards,
alexander.