This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of CD1 status.
Section: 33.5.4 [atomics.order] Status: CD1 Submitter: Jens Maurer Opened: 2008-03-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 CD1 status.
Discussion:
33.5.4 [atomics.order] p1 says in the table that
Element Meaning memory_order_acq_rel
the operation has both acquire and release semantics
To my naked eye, that seems to imply that even an atomic read has both acquire and release semantics.
Then, p1 says in the table:
Element Meaning memory_order_seq_cst
the operation has both acquire and release semantics, and, in addition, has sequentially-consistent operation ordering
So that seems to be "the same thing" as memory_order_acq_rel
, with additional
constraints.
I'm then reading p2, where it says:
The
memory_order_seq_cst
operations that load a value are acquire operations on the affected locations. Thememory_order_seq_cst
operations that store a value are release operations on the affected locations.
That seems to imply that atomic reads only have acquire semantics. If that
is intended, does this also apply to memory_order_acq_rel
and the individual
load/store operations as well?
Also, the table in p1 contains phrases with "thus" that seem to indicate consequences of normative wording in 6.9.2 [intro.multithread]. That shouldn't be in normative text, for the fear of redundant or inconsistent specification with the other normative text.
Double-check 33.5.8.2 [atomics.types.operations] that each operation clearly says whether it's a load or a store operation, or both. (It could be clearer, IMO. Solution not in current proposed resolution.)
33.5.4 [atomics.order] p2: What's a "consistent execution"? It's not defined in 6.9.2 [intro.multithread], it's just used in notes there.
And why does 33.5.8.2 [atomics.types.operations] p9 for "load" say:
Requires: The order argument shall not be
memory_order_acquire
normemory_order_acq_rel
.
(Since this is exactly the same restriction as for "store", it seems to be a typo.)
And then: 33.5.8.2 [atomics.types.operations] p12:
These operations are read-modify-write operations in the sense of the "synchronizes with" definition (6.9.2 [intro.multithread]), so both such an operation and the evaluation that produced the input value synchronize with any evaluation that reads the updated value.
This is redundant with 6.9.2 [intro.multithread], see above for the reasoning.
[ San Francisco: ]
Boehm: "I don't think that this changes anything terribly substantive, but it improves the text."
Note that "Rephrase the table in as [sic] follows..." should read "Replace the table in [atomics.order] with the following...."
The proposed resolution needs more work. Crowl volunteered to address all of the atomics issues in one paper.
This issue is addressed in N2783.
Proposed resolution:
edit 33.5.4 [atomics.order], paragraph 1 as follows.
The enumeration
memory_order
specifies the detailed regular (non-atomic) memory synchronization order as defined inClause 1.7section 1.10 and may provide for operation ordering. Its enumerated values and their meanings are as follows:
- For
memory_order_relaxed
,- no operation orders memory.
- For
memory_order_release
,memory_order_acq_rel
, andmemory_order_seq_cst
,- a store operation performs a release operation on the affected memory location.
- For
memory_order_consume
,- a load operation performs a consume operation on the affected memory location.
- For
memory_order_acquire
,memory_order_acq_rel
, andmemory_order_seq_cst
,- a load operation performs an acquire operation on the affected memory location.
remove table 136 in 33.5.4 [atomics.order].
Table 136 — memory_order effectsElementMeaningmemory_order_relaxed
the operation does not order memorymemory_order_release
the operation performs a release operation on the affected memory location, thus making regular memory writes visible to other threads through the atomic variable to which it is appliedmemory_order_acquire
the operation performs an acquire operation on the affected memory location, thus making regular memory writes in other threads released through the atomic variable to which it is applied visible to the current threadmemory_order_consume
the operation performs a consume operation on the affected memory location, thus making regular memory writes in other threads released through the atomic variable to which it is applied visible to the regular memory reads that are dependencies of this consume operation.memory_order_acq_rel
the operation has both acquire and release semanticsmemory_order_seq_cst
the operation has both acquire and release semantics, and, in addition, has sequentially-consistent operation ordering
edit 33.5.4 [atomics.order], paragraph 2 as follows.
TheTherememory_order_seq_cst
operations that load a value are acquire operations on the affected locations. Thememory_order_seq_cst
operations that store a value are release operations on the affected locations. In addition, in a consistent execution, theremust beis a single total order S on allmemory_order_seq_cst
operations, consistent with the happens before order and modification orders for all affected locations, such that eachmemory_order_seq_cst
operation observes either the last preceding modification according to this order S, or the result of an operation that is notmemory_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]