Subj : Re: Memory Barriers, Compiler Optimizations, etc.
To   : comp.programming.threads
From : Scott Meyers
Date : Sun Feb 06 2005 06:04 am

On Sat, 5 Feb 2005 17:26:11 -0800, David Schwartz wrote:
>     This is a meaningless requirement because it doesn't say *where* the 
> order needs to be preserved. One could argue that an L2 cache violates this 
> requirment and the C standard requires you to disable the L2 cache for 
> volatile accesses. The problem is that the standard simply calls the order 
> of such accesses part of the 'oberservable behavior' of the program with no 
> concept of how or where such a thing is to be observed.

I'd imagine it's the observable behavior of the abstract machine, not any
real machine, since the entire standard involves only an abstract machine.
My take would be if x and y are volatile and the generated code (program
order) accesses x before y, the compiler is off the hook, regardless of
what happens on any real machine at runtime.  After all, single
threaded-programs will always behave as if x is accessed before y,
regardless of what the hardware does (at least that's my understanding),
and the standards have no concept of more than one thread.  I can imagine
programmers wanting stronger guarantees, but I can't imagine compiler
writers offering weaker guarantees.  Are there real compiliers where use of
volatile does not have the effect of totally ordering accesses in the
generated code to volatile data?

Scott

.