Section: 33.5.4 [atomics.order] Status: Resolved Submitter: Hans Boehm Opened: 2011-02-26 Last modified: 2016-01-28 10:19:27 UTC
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 33.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