[cpp-threads] static locals

[Boehm, Hans]

Looking at this again, I agree that this is less clear than I thought,
and we could probably fix things to require thread-safety.

But consider something like

void (int my_thread_id) {
	thread_info[my_thread_id] = ...;
	static int master_thread_id = my_thread_id;

	...thread_info[master_thread_id]...

}

It is unlikely that the initialization of master_thread_id would
be done statically, but I think there's no rule that currently
prevents it.  And it's conceivable that on some systems, the
same thread would always "win", and therefore master_thread_id
is, in some weak sense, constant.

I don't think there's a rule that requires it to be in any
sense constant to be statically initialized.  Thus I think there's
also a concern here that the barrier could be elided with the argument
that it behaves "as if" the initialization were static.

I think the main issue here is whether the overhead for thread-safety
is generally acceptable.  If it is, I suspect we could strengthen
the rules on static initialization sufficiently to make this work.

Hans

> -----Original Message-----
> From: 
> Cpp-threads_decadentplace.org.uk-bounces at decadentplace.org.uk 
> [mailto:Cpp-threads_decadentplace.org.uk-bounces at decadentplace
> .org.uk] On Behalf Of Andrei Alexandrescu
> Sent: Tuesday, May 31, 2005 6:50 PM
> To: cpp-threads at decadentplace.org.uk
> Subject: Re: [cpp-threads] static locals
> 
> 
> Peter Dimov wrote:
> > Boehm, Hans wrote:
> > 
> >> I understand.
> >>
> >> But so far, having the compiler perform an initialization 
> statically, 
> >> when it is not required to, should be transparent to all 
> reasonable 
> >> code.  It is detectable, but it isn't very natural to 
> write code that 
> >> depends on the initialization happening dynamically.
> >>
> >> In the multithreaded case, I think it will not be that 
> unusual that 
> >> static initialization would break the code, since the necessary 
> >> memory ordering would no longer be enforced.  If we allow static 
> >> initialization only for constant expressions, then we 
> might start to 
> >> see bogus casts or other mechanisms solely to force 
> something not to 
> >> be a constant expression.  This bothers me.
> 
> I, too, can't figure out under what conditions static initialization 
> would break the code.
> 
> My current understanding of the C++ standard and of the static 
> initialization rules is the following:
> 
> 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. Of course, a compiler 
> could fool you if you could never tell.
> 
> 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.
> 
> I feel I'm missing something though. What is that?
> 
> 
> Andrei
> 
> -- 
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk 
> http://decadentplace.org.uk/mailman/listinfo/cpp-threads_decad
entplace.org.uk