This is the mail archive of the
mailing list for the GCC project.
RE: Optimization of conditional access to globals: thread-unsafe?
On Fri, 2007-10-26 at 16:24 +0100, Dave Korn wrote:
> On 26 October 2007 16:15, Robert Dewar wrote:
> > One problem at the language standards level is that you can't easily
> > talk about loads and stores, since you are defining an as-if semantic
> > model, and if you make a statement about loads and stores, any other
> > sequence which behaves as if that sequence were obeyed is allowed.
> Well, that's precisely the problem - specifically in the context of
> memory-mapped I/O registers - that volatile was invented to solve. It may
> never have been clearly defined in the formal language of the specs, but I
> thought it was pretty clear in intent: the compiler will emit exactly one
> machine load/store operation for any rvalue reference/lvalue assignment
> (respectively) in the source, at the exact sequence point in the generated
> code corresponding to the location of the reference in the source. Any other
> variable may be accessed more or fewer times than is written, and may be
> accessed at places other than exactly where the reference is written in the
> source, subject only to the as-if rule.
Volatile semantics aren't defined, you have it backwards.
Bart hinted at the way it really works: it isn't a definition,
and it isn't a specification: volatile is part of the
*conformance* model. Volatile accesses are *observable*.
So when the standard says of:
int a = 1;
int b = 2;
that a is initialised then b, the compiler can ignore the standard,
because there is no observable way to tell what the ordering is,
except that it has to be complete before the print happens.
If a,b above were volatile .. then the ordering is directly
observable, so the compiler is constrained to obey the
The point is -- there is no new rule here, and no definition
of what a volatile semantics is: volatile variables have
the SAME 'semantics' as any other variable. If I write:
int a = 1;
int b = 2;
then it is just the same as if a,b were volatile.
In fact I could put
instead of the printf .. sin is a library function.
This means a debugger with a breakpoint on the sin can be
used to bug out the compiler as non-conforming if 'a' isn't
set (or, if b IS set) .. but print statements are easier :)
Stick a user defined function in there, which itself isn't
observable .. and all bets are off again.
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net