Re: Consensus on MT-, AS- and AC-Safety docs.

[Torvald Riegel <triegel at redhat dot com>]

On Sun, 2013-12-01 at 13:08 -0500, Rich Felker wrote:
> On Sun, Dec 01, 2013 at 07:06:05PM +0100, Torvald Riegel wrote:
> > > It
> > > doesn't cover all of the richness of the atomics of recent C and C++
> > > standards, but a basic memory model in which they can fit in perfectly
> > > is there: concurrent writes or reads and writes to the same memory
> > > location, without intervening synchronization operations, invoke
> > > undefined behavior.  This is the memory model that POSIX exposes to
> > > users.
> > 
> > That's not a complete definition, obviously.  That's an attempt at
> > describing the rough idea behind a memory model.
> 
> That is a memory model. It may not be the ideal memory model we want,
> but it's a memory model because it defines the situations in which
> memory accesses are well-defined and explicitly leaves the behavior
> completely undefined in all other cases.

Just a few examples here:
* The standard states (Base definitions 4.11, Memory Synchronization,
2013 version) that "memory is synchronized" on calls to synchronization
objects -- but what does that mean precisely (ie, where's the
definition)?
* What does "while another thread modifies it" mean exactly? Just mutual
exclusion is not sufficient to make this work because there's no
ordering aspect to it, you also need some kind of ordering constraints
that ensure consistency wrt. the values that the program reads.
* Where is program order taken into account?

Thus, you need to kind of guess what's going on in detail.  I don't
think that it's likely that different people's guesses might differ a
lot, but there are subtleties in it that users need to guess right
about; the standard mentions that both thread execution (ie, ordering)
and memory sync play a role, but in which way this happens is up to the
user to figure out.

For example, when acquiring a mutex, which state of memory does the
critical section start with (ie, "synchronize" with)?  It's not
forbidden that this would be the state produced by an earlier unlock
(ie, not the most recent unlock from an implementation perspective).  We
would certainly all agree that this would be an impractical
implementation, but I don't see it being forbidden by the standard.  We
likely all share an implicit understanding of what the full mutex
requirements are to make them practical, but that's different from the
standard having a complete definition.
C11, in contrast, does take care of this by explicitly relating
reads-from relations, program order, and per-mutex total orders of
lock/unlock, requiring that they be consistent in an execution.  That's
independent of all the atomics and such in the model.  It just makes
sure to spell out the requirements, and relate the synchronization to
semantics of program execution.