| Doc. no.: | N1856 |
|---|---|
| Date: | 2014-07-02 |
| Reply to: | Clark Nelson |
I was given the action item to report back on WG21's progress on the issues WG14 designates DR 406 and DR 407.
DR 406 corresponds to CWG issue 1466, q.v. for more information. Wording changes were accepted at the 2014-02 (Issaquah) meeting. The changes are duplicated below.
DR 407 corresponds to LWG issue 2130, q.v. for more information. Wording changes were accepted at the 2013-04 (Bristol) meeting. The changes are duplicated below.
The changes below are verbatim from the C++ issues lists, except that, where possible, the section and paragraph references have been changed to refer to the C working draft (N1570). Unfortunately, the (preserved or deleted) previous text does not in all cases exactly match what is in N1570. I have tried to track down the sources of the differences.
Most of the most significant changes were made as specified in WG21/N3196 (“Omnibus Memory Model and Atomics Paper”) adopted in 2010-10 (Batavia). Those changes include, among many others, the adoption of four paragraphs of coherence requirements, and two paragraphs of associated notes. They explain the discrepancies encountered in 5.1.2.4 paragraph 22. Also, the drafting note to the editor associated with DR 407 is targeted to the write-write coherence rule.
Paragraph 24 of 5.1.2.4 seems to have been editorially tweaked by WG14. Paragraph 27 of 5.1.2.4 seems to have been editorially tweaked by WG21. At this point, these tweaks need not concern WG14.
The history of changes relevant to 7.17.3 is particularly complicated.
The edit below from the WG21 issue list replaces an existing paragraph, but as far as I can tell, with respect to N1570, the new text should instead be added as a new paragraph after paragraph 11.
The note indicated below as following this paragraph (i.e., the one about ensuring sequential consistency) was added to C++ in response to LWG issue 926 (“Sequentially consistent fences, relaxed operations and modification order”), and/or WG21/N2992 (“More Collected Issues with Atomics”).
In addition, paragraphs 13 and 14 have recently (2013-09) been rewritten in C++ by WG21/N3786 (“Prohibiting "out of thin air" results in C++14”).
(Paragraph 12 is substantially identical to a paragraph which appears at a slightly different location in C++; there are differences, but they are just editorial.)
Change 5.1.2.4 paragraph 22 as follows:
The visible sequence of side effects on an atomic object M, with respect to a value computation B of M, is a maximal contiguous sub-sequence of side effects in the modification order of M, where the first side effect is visible with respect to B, and for every side effect, it is not the case that B happens before it.The value of an atomic object M, as determined by evaluation B, shall be the value stored by someoperation in the visible sequence of M with respect to Bside effect A that modifies M, where B does not happen before A. [Note:It can be shown that the visible sequence of side effects of a value computation is unique givenThe set of side effects that a given evaluation might take its value from is also restricted by the rest of the rules described here, and in particular, by the coherence requirements below. —end note]
Change 5.1.2.4 paragraph 24 as follows:
[Note: The
visible sequence of side effectsvalue observed by a load of an atomic depends on the “happens before” relation, which depends on the values observed by loads of atomics, which we are restricting here. The intended reading is that there must exist an association of atomic loads with modifications they observe that, together with suitably chosen modification orders and the “happens before” relation derived as described above, satisfy the resulting constraints as imposed here. —end note]
Change 5.1.2.4 paragraph 27 as follows:
[Note: Compiler transformations that introduce assignments to a potentially shared memory location that would not be modified by the abstract machine are generally precluded by this standard, since such an assignment might overwrite another assignment by a different thread in cases in which an abstract machine execution would not have encountered a data race. This includes implementations of data member assignment that overwrite adjacent members in separate memory locations. Reordering of atomic loads in cases in which the atomics in question may alias is also generally precluded, since this may violate the
“visible sequence”coherence rules. —end note]
Change 7.17.3 paragraph 6 as follows:
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 B that loads a value from an atomic object M observes one of the following values:
the result of the last modification A of M that precedes B in S, if it exists, or
if A exists, the result of some modification of M
in the visible sequence of side effects with respect to Bthat is not memory_order_seq_cst and that does not happen before A, orif A does not exist, the result of some modification of M
in the visible sequence of side effects with respect to Bthat is not memory_order_seq_cst.[Note:...
[Drafting note: The project editor is kindly asked to consider to replace in 1.10 [intro.multithread] p17 the phrase "before an operation B on M" by "before a modification B of M".]
Change 7.17.3 paragraph 11 as indicated: [Drafting note: Note that the wording change intentionally does also replace the term atomic operation by atomic modification]
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:
[ 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 ]