2034. Initialization of atomics is misspecified so that it doesn't preserve sequential consistency

Section: 32.5.4 [atomics.order] Status: Resolved Submitter: Hans Boehm Opened: 2011-02-26 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 Resolved status.

Discussion:

This violates the core intent of the memory model, as stated in the note in 6.9.2 [intro.multithread] p. 21.

This was discovered by Mark Batty, and pointed out in their POPL 2011 paper, "Mathematizing C++ Concurrency", section 4, "Sequential consistency of SC atomics". The problem is quite technical, but well-explained in that paper.

This particular issue was not understood at the time the FCD comments were generated. But it is closely related to a number of FCD comments. It should have arisen from US-171, though that's not the actual history.

This issue has been under discussion for several months in a group that included a half dozen or so of the most interested committee members. The P/R represents a well-considered consensus among us:

[2011-03-16: Jens updates wording]

Modify 32.5.4 [atomics.order] p.3, so that the normative part reads:

3 There shall be a single total order S on all memory_order_seq_cst operations, consistent with the "happens before" order and modification orders for all affected locations, such that each memory_order_seq_cst operation that loads a value observes either the last preceding modification according to this order S, A (if any), or the result of an operation X that is notdoes not happen before A and that is not memory_order_seq_cst. [ Note: Although it is not explicitly required that S include locks, it can always be extended to an order that does include lock and unlock operations, since the ordering between those is already included in the "happens before" ordering. — end note ]

Proposed resolution:

Resolved 2011-03 Madrid meeting by paper N3278