Re: Heads-up: volatile and C++

[Geoffrey Keating <geoffk at geoffk dot org>]

Jason Merrill <jason@redhat.com> writes:

> On Thu, 14 Apr 2005 10:12:37 -0400, "Michael N. Moran" <mike@mnmoran.org> wrote:
> 
> > 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.
> >
> > As someone who uses the C++ language and multi-threading
> > extensively in embedded systems, I have come to the following
> > belief/opinion.
> >
> >    The language (C++) *should not* have dependencies
> >    upon threading. IMHO, threading is a layer above a
> >    systems programming language, and having dependencies
> >    upon upper layers is evil.
> 
> But the memory model for the language must provide semantics that make it
> possible for threaded programs to be written.  Currently, if you want to
> write a portable pthreads program you need to use a mutex around all uses
> of shared memory, because they are the only way to guarantee sequential
> memory ordering.  The volatile proposal provides a lighter-weight way to
> write portable code with explicit memory ordering.  You need this for
> lockless algorithms to work.
...
> It seems to me that the current specification of volatile already requires
> an lwsync around volatile reads and writes, to guarantee that all previous
> stores have been completed and later ones have not started.

The key question is "completed as seen by whom?"  At present, GCC
answers that question with "instructions on the same processor".  It
would certainly be possible, and useful, to have a (different) mode in
which the answer was "instructions on any processor, even with a
cache-unsynchronized memory map".  It'd be much harder to have a mode
where the answer was "anyone who can see the file system", since that
requires calling msync().