Jason Merrill wrote:
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.
Could you clarify whether 'other writes' means 'other _volatile_ writes',
or '_any_ other writes'? Since non-volatile writes are not visible
outside of the abstract machine, how can they be ordered wrt volatiles?
It seems to me that threads require barriers _within_ the abstract machine,
and currently there is no mechanism to specify just that. Volatile is all
we have, and AFAICT those are only ordered WRT other volatile accesses
separated by a sequence point.
It appears to me that the proposal is providing more restrictions
on volatile and other accesses, not fewer -- and cursorily that seems
sane.
nathan
--
Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery LLC
[EMAIL PROTECTED] :: http://www.planetfall.pwp.blueyonder.co.uk
