This page is a snapshot from the LWG issues list, see theLibrary Active Issues List for more information and the meaning ofResolved status.
Section: 32.5.4[atomics.order]Status:ResolvedSubmitter: Hans BoehmOpened: 2011-02-26Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [atomics.order].
View all otherissues in [atomics.order].
View all issues withResolved status.
Discussion:
This violates the core intent of the memory model, as stated in the note in 6.10.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 fromUS-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 orderS on all
memory_order_seq_cstoperations, consistent with the "happens before" order and modification orders for all affected locations, such that eachmemory_order_seq_cstoperation that loads a value observes either the last preceding modification according to this orderS,A (if any), or the result of an operationX thatis notdoes not happen beforeA and that is notmemory_order_seq_cst. [Note: Although it is not explicitly required thatS 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 paperN3278