The C++ committee (well, a subgroup represented at this meeting by Hans
Boehm) is working on a memory model that supports threaded programs. One
proposed change is to the semantics of volatile. Currently, volatile
semantics are constrained by:
6 The observable behavior of the abstract machine is its sequence of
reads and writes to volatile data and calls to library I/O
functions.6)
7 Accessing an object designated by a volatile lvalue (_basic.lval_),
modifying an object, calling a library I/O function, or calling a
function that does any of those operations are all side effects, which
are changes in the state of the execution environment. Evaluation of
an expression might produce side effects. At certain specified points
in the execution sequence called sequence points, all side effects of
previous evaluations shall be complete and no side effects of
subsequent evaluations shall have taken place.7)
My reading of this is that currently, a volatile read or write should act
as a barrier to other writes ("modifying an object"), because generally
there will be a sequence point between those writes and the volatile
access.
The proposal is that volatile reads act as an acquire (hoist barrier), and
volatile writes act as a release (sink barrier). These precisely
correspond to the ia-64 ld.acq and st.rel instructions; other architectures
may or may not need memory barrier instructions. Hans suggests that these
semantics are already required by the Itanium documentation.
The difference from this from what I percieve the current standard to say
is
1) volatile reads and writes now inhibit movement of loads in one direction
(and therefore constrain CSE).
2) movement of stores is allowed in one direction across volatile reads and
writes, where before it was fully blocked.
This all makes sense to me, but I'm interested in feedback.
Jason
