[cpp-threads] Brief example ITANIUM Implementation forC/C++MemoryModel

[Paul E. McKenney]

On Sat, Jan 03, 2009 at 01:01:06AM +0200, Peter Dimov wrote:
> Alexander Terekhov:
> > So where do you put an additional fence(seq_cst) in
> >
> > P1: Y.store(1, relaxed);
> > P2: Z.store(1, relaxed); fence(seq_cst); a = Y.load(relaxed);
> > P3: b = Y.load(relaxed); fence(seq_cst); c = Z.load(relaxed);
> >
> > to preclude non-sequentially consistent  a=0, b=1, c=0 outcome?
> 
> I'd say that this is a defect in the specification of fence(seq_cst). 
> There's one issue against it:
> 
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2806.html#926

I missed this one.  Strange, though...  The proposed resolution is to
add a new paragraph in 29.1 as follows:

	For atomic operations A and B on an atomic object M, where A and
	B modify M, if there are memory_order_seq_cst fences X and Y
	such that A is sequenced before X, Y is sequenced before B, and
	X precedes Y in S, then B occurs later than A in the modifiction
	order of M.

Assuming s/modifiction/modification/, doesn't the modification-order
wording already guarantee this ordering for atomic operations?

> but it's about two stores separated by seq_cst fences. Looks like we need 
> additional wording about loads separated by seq_cst fences as well. 
> Something like:
> 
> "For atomic operations A and B that read the value of an atomic object M, if 
> there are memory_order_seq_cst fences X and Y such that A is sequenced 
> before X, Y is sequenced before B, and X precedes Y in S, then B shall 
> either read the same value as A, or a later value in the modifiction order 
> of M."
> 
> Does this sound OK as a proposed resolution? Do we agree that the example 
> should be SC? 

In Alexander's example above, the issue is not the order of the loads,
but rather the order of P1's and P2's stores to different atomic
variables.  Power uses cumulativity to allow the fences between the
loads to force a globally consistent order, but other architectures act
differently -- for example, x86 would require that the two stores use
atomic RMW operations.

So I do not believe that the fence(seq_cst) can guarantee SC in all
examples, due to the variety in the memory-ordering instructions in the
various architectures.  I do not believe that this is a defect in the
standard, though it might be yet another surprise for people attempting
to naively mix SC and non-SC operations.  ;-)

							Thanx, Paul