> "Volatile behaviour" itself isn't consistently defined (at least
It should be consistent across platforms; if not, file a bug please.
You can *expect* whatever you want, but this isn't in line with
reality at all.
volatile _does not_ make accesses go all the way to memory.
volatile _does not_ prevent reordering wrt other accesses.
What volatile does are a) never optimise away a read (or write)
to the object, since the data can change in ways the compiler
cannot see; and b) never move stores to the object across a
sequence point. This does not mean other accesses cannot be
reordered wrt the volatile access.
If the abstract machine would do an access to a volatile-
qualified object, the generated machine code will do that
access too. But, for example, it can still be optimised
away by the compiler, if it can prove it is allowed to.
If you want stuff to go all the way to memory, you need some
architecture-specific flush sequence; to make a store globally
visible before another store, you need mb(); before some following
read, you need mb(); to prevent reordering you need a barrier.
Segher
-
