*This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++14 status.*

**Section:** 33.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 33.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.

*[Drafting note: The project editor is kindly asked to consider to replace in 6.9.2 [intro.multithread] p17 the phrase**"before an operation*by*B*on*M*"*"before a modification*.]*B*of*M*"Change 33.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~~For atomic modifications*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*.*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*]- there is a