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

Peter Dimov pdimov at mmltd.net
Fri Jan 2 23:01:06 GMT 2009


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

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? 




More information about the cpp-threads mailing list