[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