This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Heads-up: volatile and C++


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
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]