[cpp-threads] static locals

Boehm, Hans hans.boehm at hp.com
Thu Jun 2 01:39:46 BST 2005


With traditional approaches to optimization, I agree.  But
that's not a restriction we can put in the standard.

As it stands, a compiler is allowed to look at the whole
program, deduce that only two threads execute this code,
observe that this code will only be run on some hypothetical
new machine where both threads run in lock-step, and hence
thread 1 will always perform the initialization first.
Thus it knows what the initialization value will be, even
though it's not the same for all valid executions.  My reading
is that static initialization is allowed in such cases.

The real issue is that the programmer has no way to
reason about visibility, since there is no rule that clearly
prohibits static initialization.

Hans

> -----Original Message-----
> From: Peter Dimov [mailto:pdimov at mmltd.net] 
> Sent: Wednesday, June 01, 2005 5:31 PM
> To: Boehm, Hans; Alexander Terekhov
> Cc: cpp-threads
> Subject: Re: [cpp-threads] static locals
> 
> 
> Boehm, Hans wrote:
> > I think we agree.  The compiler is unlikely to perform the 
> > initialization statically, but when writing this code, it's 
> hard for 
> > the programmer to preclude that possibility.  If we were to go this 
> > route, we'd have to add something to 3.6.2/2, (e.g. a 
> requirement that 
> > the initializer
> > return the same value in all legal executions), which probably
> > wouldn't be a huge deal.
> 
> I don't think that such a requirement is needed, given the 
> second bullet of 
> 3.6.2/2; I can't think of a case where early init would be 
> valid under 
> 3.6.2/2 but invalid under the "same value in all legal 
> executions" rule. 
> 
> 




More information about the cpp-threads mailing list