Heads-up: volatile and C++

[Jason Merrill <jason at redhat dot com>]

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