<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 818: wording for memory ordering</title>
<meta property="og:title" content="Issue 818: wording for memory ordering">
<meta property="og:description" content="C++ library issue. Status: CD1">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue818.html">
<meta property="og:type" content="website">
<meta property="og:image" content="http://cplusplus.github.io/LWG/images/cpp_logo.png">
<meta property="og:image:alt" content="C++ logo">
<style>
  p {text-align:justify}
  li {text-align:justify}
  pre code.backtick::before { content: "`" }
  pre code.backtick::after { content: "`" }
  blockquote.note
  {
    background-color:#E0E0E0;
    padding-left: 15px;
    padding-right: 15px;
    padding-top: 1px;
    padding-bottom: 1px;
  }
  ins {background-color:#A0FFA0}
  del {background-color:#FFA0A0}
  table.issues-index { border: 1px solid; border-collapse: collapse; }
  table.issues-index th { text-align: center; padding: 4px; border: 1px solid; }
  table.issues-index td { padding: 4px; border: 1px solid; }
  table.issues-index td:nth-child(1) { text-align: right; }
  table.issues-index td:nth-child(2) { text-align: left; }
  table.issues-index td:nth-child(3) { text-align: left; }
  table.issues-index td:nth-child(4) { text-align: left; }
  table.issues-index td:nth-child(5) { text-align: center; }
  table.issues-index td:nth-child(6) { text-align: center; }
  table.issues-index td:nth-child(7) { text-align: left; }
  table.issues-index td:nth-child(5) span.no-pr { color: red; }
  @media (prefers-color-scheme: dark) {
     html {
        color: #ddd;
        background-color: black;
     }
     ins {
        background-color: #225522
     }
     del {
        background-color: #662222
     }
     a {
        color: #6af
     }
     a:visited {
        color: #6af
     }
     blockquote.note
     {
        background-color: rgba(255, 255, 255, .10)
     }
  }
</style>
</head>
<body>
<hr>
<p><em>This page is a snapshot from the LWG issues list, see the <a href="lwg-active.html">Library Active Issues List</a> for more information and the meaning of <a href="lwg-active.html#CD1">CD1</a> status.</em></p>
<h3 id="818"><a href="lwg-defects.html#818">818</a>. wording for memory ordering</h3>
<p><b>Section:</b> 32.5.4 <a href="https://wg21.link/atomics.order">[atomics.order]</a> <b>Status:</b> <a href="lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2008-03-22 <b>Last modified:</b> 2016-01-28</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View other</b> <a href="lwg-index-open.html#atomics.order">active issues</a> in [atomics.order].</p>
<p><b>View all other</b> <a href="lwg-index.html#atomics.order">issues</a> in [atomics.order].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
32.5.4 <a href="https://wg21.link/atomics.order">[atomics.order]</a> p1 says in the table that
</p>

<blockquote>
<table border="1">
<tr>
<th>Element</th><th>Meaning</th>
</tr>
<tr>
<td><code>memory_order_acq_rel</code></td>
<td>the operation has both acquire and release semantics</td>
</tr>
</table>
</blockquote>

<p>
To my naked eye, that seems to imply that even an atomic read has both
acquire and release semantics.
</p>

<p>
Then, p1 says in the table:
</p>

<blockquote>
<table border="1">
<tr>
<th>Element</th><th>Meaning</th>
</tr>
<tr>
<td><code>memory_order_seq_cst</code></td>
<td>the operation has both acquire and release semantics,
    and, in addition, has sequentially-consistent operation ordering</td>
</tr>
</table>
</blockquote>

<p>
So that seems to be "the same thing" as <code>memory_order_acq_rel</code>, with additional
constraints.
</p>

<p>
I'm then reading p2, where it says:
</p>

<blockquote><p>
The <code>memory_order_seq_cst</code> operations that load a value are acquire operations
on the affected locations. The <code>memory_order_seq_cst</code> operations that store a value
are release operations on the affected locations.
</p></blockquote>

<p>
That seems to imply that atomic reads only have acquire semantics.  If that
is intended, does this also apply to <code>memory_order_acq_rel</code> and the individual
load/store operations as well?
</p>

<p>
Also, the table in p1 contains phrases with "thus" that seem to indicate
consequences of normative wording in 6.10.2 <a href="https://wg21.link/intro.multithread">[intro.multithread]</a>.  That shouldn't be in
normative text, for the fear of redundant or inconsistent specification with
the other normative text.
</p>

<p>
Double-check 32.5.8.2 <a href="https://wg21.link/atomics.types.operations">[atomics.types.operations]</a> 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.)
</p>

<p>
32.5.4 <a href="https://wg21.link/atomics.order">[atomics.order]</a> p2:  What's a "consistent execution"?  It's not defined in
6.10.2 <a href="https://wg21.link/intro.multithread">[intro.multithread]</a>, it's just used in notes there.
</p>

<p>
And why does 32.5.8.2 <a href="https://wg21.link/atomics.types.operations">[atomics.types.operations]</a> p9 for "load" say:
</p>


<blockquote><p>
<i>Requires:</i> The order argument shall not be <code>memory_order_acquire</code>
nor <code>memory_order_acq_rel</code>.
</p></blockquote>

<p>
(Since this is exactly the same restriction as for "store", it seems to be a typo.)
</p>

<p>
And then: 32.5.8.2 <a href="https://wg21.link/atomics.types.operations">[atomics.types.operations]</a> p12:
</p>

<blockquote><p>
These operations are read-modify-write operations in the sense of the
"synchronizes with" definition (6.10.2 <a href="https://wg21.link/intro.multithread">[intro.multithread]</a>), so both such an operation and the
evaluation that produced the input value synchronize with any evaluation
that reads the updated value.
</p></blockquote>

<p>
This is redundant with 6.10.2 <a href="https://wg21.link/intro.multithread">[intro.multithread]</a>, see above for the reasoning.
</p>

<p><i>[
San Francisco:
]</i></p>


<blockquote>
<p>
Boehm: "I don't think that this changes anything terribly substantive,
but it improves the text."
</p>
<p>
Note that "Rephrase the table in as [sic] follows..." should read
"Replace the table in [atomics.order] with the following...."
</p>
<p>
The proposed resolution needs more work. Crowl volunteered to address
all of the atomics issues in one paper.
</p>

<p>
This issue is addressed in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2783.htm">N2783</a>.
</p>
</blockquote>


<p id="res-818"><b>Proposed resolution:</b></p>
<p>
edit 32.5.4 <a href="https://wg21.link/atomics.order">[atomics.order]</a>, paragraph 1 as follows.
</p>

<blockquote>
<p>
The enumeration <code>memory_order</code>
specifies the detailed regular (non-atomic) memory synchronization order
as defined in <del>Clause 1.7</del> <ins>section 1.10</ins>
and may provide for operation ordering.
Its enumerated values and their meanings are as follows:
</p>
<blockquote>
<dl>
<dt><ins>For <code>memory_order_relaxed</code>,</ins></dt>
<dd><ins>no operation orders memory.</ins></dd>
<dt><ins>For <code>memory_order_release</code>,
<code>memory_order_acq_rel</code>,
and <code>memory_order_seq_cst</code>,</ins></dt>
<dd><ins>a store operation performs a release operation
on the affected memory location.</ins></dd>
<dt><ins>For <code>memory_order_consume</code>,</ins></dt>
<dd><ins>a load operation performs a consume operation
on the affected memory location.</ins></dd>
<dt><ins>For <code>memory_order_acquire</code>,
<code>memory_order_acq_rel</code>,
and <code>memory_order_seq_cst</code>,</ins></dt>
<dd><ins>a load operation performs an acquire operation
on the affected memory location.</ins></dd>
</dl>
</blockquote>
</blockquote>

<p>
remove table 136 in 32.5.4 <a href="https://wg21.link/atomics.order">[atomics.order]</a>.
</p>

<blockquote>
<table border="1">
<caption><del>Table 136 &mdash; memory_order effects</del></caption>
<tr><th><del>Element</del></th><th><del>Meaning</del></th></tr>
<tr><td valign="top"><del><code>memory_order_relaxed</code></del></td>
<td valign="top"><del>the operation does not order memory</del></td></tr>
<tr><td valign="top"><del><code>memory_order_release</code></del></td>
<td valign="top"><del>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 applied</del></td></tr>
<tr><td valign="top"><del><code>memory_order_acquire</code></del></td>
<td valign="top"><del>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 thread</del></td></tr>
<tr><td valign="top"><del><code>memory_order_consume</code></del></td>
<td valign="top"><del>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.</del></td></tr>
<tr><td valign="top"><del><code>memory_order_acq_rel</code></del></td>
<td valign="top"><del>the operation has both acquire and release semantics</del></td></tr>
<tr><td valign="top"><del><code>memory_order_seq_cst</code></del></td>
<td valign="top"><del>the operation has both acquire and release semantics,
and, in addition, has sequentially-consistent operation ordering</del></td></tr>
</table>
</blockquote>

<p>
edit 32.5.4 <a href="https://wg21.link/atomics.order">[atomics.order]</a>, paragraph 2 as follows.
</p>

<blockquote>
<p>
<del>The <code>memory_order_seq_cst</code> operations that load a value
are acquire operations on the affected locations.
The <code>memory_order_seq_cst</code> operations that store a value
are release operations on the affected locations.
In addition, in a consistent execution,
there</del> <ins>There</ins> <del>must be</del> <ins>is</ins>
a single total order <var>S</var>
on all <code>memory_order_seq_cst</code> operations,
consistent with the happens before order
and modification orders for all affected locations,
such that each <code>memory_order_seq_cst</code> operation
observes either the last preceding modification
according to this order <var>S</var>,
or the result of an operation that is not <code>memory_order_seq_cst</code>.
[<i>Note:</i>
Although it is not explicitly required that <var>S</var> 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.
&mdash;<i>end note</i>]
</p>
</blockquote>






</body>
</html>
