2130. Missing ordering constraints

Section: 32.5.4 [atomics.order] Status: C++14 Submitter: Mark Batty Opened: 2012-02-22 Last modified: 2016-01-28

Priority: Not Prioritized

View other active issues in [atomics.order].

View all other issues in [atomics.order].

View all issues with C++14 status.

Discussion:

C11 issue 407

It seems that both C11 and C++11 are missing the following two derivatives of this rule:

For atomic modifications A and B of an atomic object M, if there is a memory_order_seq_cst fence X such that A is sequenced before X, and X precedes B in S, then B occurs later than A in the modification order of M.

For atomic modifications A and B of an atomic object M, if there is a memory_order_seq_cst fence Y such that Y is sequenced before B, and A precedes Y in S, then B occurs later than A in the modification order of M.

Above wording has been suggested for the Technical Corrigendum of C11 via issue 407, details can be found here.

[2012-03-19: Daniel proposes a slightly condensed form to reduce wording duplications]

[2012-03-20: Hans comments]

The usage of the term atomic operations in 32.5.4 [atomics.order] p7 is actually incorrect and should better be replaced by atomic modifications as used in the C11 407 wording.

There seems to be a similar wording incorrectness used in 6.9.2 [intro.multithread] p17 which should be corrected as well.

[2012, Portland: move to Review]

Olivier: does the fence really participate in the modifications?

Hans: S is the total set of all sequentially consistent operations, and sequentially consistent fences are in S.

Olivier: this sort of combination of a pair of half-open rules seems to imply the write must make it to main memory

But not all implementations treat a fence as a memory operation; cannot observe the half-open rule.

Hans: not sure this is actually prevented here. You could defer until the next load. What the wording doesn't quite show is that the third bullet in the new wording is already in the standard.

Hans: it is the interaction between fences on one side and other memory modifications on the other that is being defined here.

Pablo: S is not directly observable; it is a hypothetic ordering.

Moved to review

Hans: to alert C liaison

[2013-04-20, Bristol]

Accepted for the working paper

Proposed resolution:

This wording is relative to N3376.

1. [Drafting note: The project editor is kindly asked to consider to replace in 6.9.2 [intro.multithread] p17 the phrase "before an operation B on M" by "before a modification B of M".]

2. Change 32.5.4 [atomics.order] paragraph 7 as indicated: [Drafting note: Note that the wording change intentionally does also replace the term atomic operation by atomic modification]

   -7- For atomic operations A and B on 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 occurs later than A in the modification order of M. For atomic modifications A and B of an atomic object M, B occurs later than A in the modification order of M if:

   • there is a memory_order_seq_cst fence X such that A is sequenced before X, and X precedes B in S, or
   • there is a memory_order_seq_cst fence Y such that Y is sequenced before B, and A precedes Y in S, or
   • 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.

   -8- [ Note: memory_order_seq_cst ensures sequential consistency only for a program that is free of data races and uses exclusively memory_order_seq_cst operations. Any use of weaker ordering will invalidate this guarantee unless extreme care is used. In particular, memory_order_seq_cst fences ensure a total order only for the fences themselves. Fences cannot, in general, be used to restore sequential consistency for atomic operations with weaker ordering specifications. — end note ]