[cpp-threads] Yet another visibility question

[Boehm, Hans]

> From:  Nelson, Clark
> > 1.10p7:
> > {Add synchronizes-with relationships back in for all writer-reader 
> > pairs of atomic memory operations.  Whether or not something is an 
> > acquire or release operation no longer affects "synchronizes-with", 
> > but it still affects "inter-thread-ordered-before" and hence 
> > "happens-before".  This means that "raw" operations can be used to 
> > synchronize threads if the "inter-thread-ordered-before"
> > relationships are introduced by other ordered operations, which now 
> > act more like fences, as they generally do on hardware.
> > We also provide per-variable TSO, which is what triggered all these 
> > changes.} "An evaluation A that performs a release operation on a 
> > location L synchronizes-with an evaluation B that performs 
> an acquire 
> > operation on L and reads the value written by A."
> > ==>
> > "All modifications to a particular memory location L occur in some 
> > particular total order, referred to as the modification order for L.
> > An evaluation A that performs a synchronization operation that 
> > modifies location L synchronizes-with an evaluation B that 
> reads the 
> > value written by A, or reads a value that was subsequently (in 
> > modification
> > order) written to L.
> 
> My main concern about this direction is adding yet another 
> ordering relation ("modification order") to the five we 
> already have ("sequenced before", "inter-thread ordered 
> before", "synchronizes with", "happens before", and "precedes").
> 
> Do we really need six ordering relations?
> 
We clearly need sequenced-before, happens-before, and precedes.  (We
could maybe get away without naming "precedes", but that doesn't sound
like an improvement.)

The remaining ones (modification order, inter-thread-ordered-before, and
synchronizes with) really just contribute to happens-before.  Thus I
guess we have a choice about whether to introduce them.  The down side
of not introducing them seems to be that it makes discussions and
explanations harder.  (I have to admit, I don't like
inter-thread-ordered-before as a name.  Getting rid of both it and
synchronizes-with might be a win.)

Thinking about my suggested change to 1.10p7 (adding synchronizes-with
relationships to all predecessors of a write),
I suspect that change is actually no longer necessary.  The earlier
writes now happen-before the later ones in modification order anyway.
Thus I think we already get the additional synchronization relationships
by transitivity.

But Ben's objection still stands.  So I think we want 

"All modifications to a particular atomic memory location or lock L
occur in some 
particular total order, referred to as the modification order for L."

somewhere else, and something along the lines of


1.10p7:
For any evaluation B that reads the value of L, there is some 
modification A such that A writes the value read by B.  If L is an
atomic memory
location or lock, we say that A synchronizes with B. [ Note: ... ]

except that we may just want to inline that directly into the
happens-before definition.

Hans