<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
   "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=US-ASCII">

<title>Collected Issues with Atomics</title>
</head>

<body>
<h1>Collected Issues with Atomics</h1>

<p>
ISO/IEC JTC1 SC22 WG21 N2783 = 08-0293 - 2008-09-18
</p>

<p>
Lawrence Crowl, Lawrence@Crowl.org, crowl@google.com
</p>


<h2>Issues</h2>

<p>
This paper collects several issues with the current atomics
and provides proposed resolutions for them.
</p>

<h3><a href="http://www.open-std.org/JTC1/SC22/WG21/docs/lwg-active.html#818">LWG 818</a> wording for memory ordering</h3>

<p>
The description of <code>memory_order</code> values
could be read to imply acquire semantics when there was no load
and release semantics when there was no store.
The solution is to reorganize the specification
to be load and store centric
rather than <code>memory_order</code> value centric.
</p>

<p>
The term "consistent execution" is not well-defined.
The solution is to reorganize the paragraph to avoid the term.
</p>

<p>
There were incorrect specifications of <code>memory_order</code> values.
These specifications have been corrected by editorial changes.
</p>

<h3><a href="http://www.open-std.org/JTC1/SC22/WG21/docs/lwg-active.html#845">LWG 845</a> atomics cannot support aggregate initialization</h3>

<p>
The current definition of atomics and list initialization
do not support the <em>syntax</em> of aggregate initialization.
(There was no requirement to support full aggregate initialization.)
The issue is that explicit constructors are not applicable
to copy-list-initialization.
The solution is to remove the explicit qualifier.
This solution is safe for all the reasons described
in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2514.html">N2514
Implicit Conversion Operators for Atomics</a>.
</p>

<h3><a href="http://www.open-std.org/JTC1/SC22/WG21/docs/lwg-active.html#846">LWG 846</a> no definition for constructor</h3>

<p>
The constexpr value constructors had neither a body nor a textual definition.
The solution is to add a textual definition.
</p>

<h3><a href="http://www.open-std.org/JTC1/SC22/WG21/docs/lwg-active.html#864">LWG 864</a> defect in atomic wording</h3>

<p>
There were incorrect specifications of <code>memory_order</code> values.
These specifications have been corrected by editorial changes.
</p>

<h2>Wording</h2>

<p>
The base document for these wording changes is
<a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2008/n2723.pdf">N2723</a>.
</p>

<h3>29.1 Order and Consistency [atomics.order]</h3>

<p>
From LWG issue 818,
edit 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>
</blockquote>
</dl>
</blockquote>

<p>
From LWG issue 818,
remove table 136.
</p>

<blockquote>
<table border=1>
<caption><del>Table 136 &mdash; memory_order effects</caption>
<tr><th><del>Element</th><th><del>Meaning</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></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>
From LWG issue 818,
edit 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>

<h3>29.3.1 Integral Types [atomics.types.integral]</h3>

<p>
For issue 845,
within the synopsis edit as follows.
</p>

<blockquote><pre><code>
....
typedef struct atomic_bool {
....
  constexpr <del>explicit</del> atomic_bool(bool);
....
typedef struct atomic_<var>itype</var> {
....
  constexpr <del>explicit</del> atomic_<var>itype</var>(<var>integral</var>);
....
</code></pre></blockquote>

<p>
For issue 845,
edit paragraph 2 as follows.
</p>

<blockquote>
The atomic integral types shall have standard layout.
They shall each have a trivial default constructor,
a constexpr <del>explicit</del> value constructor,
a deleted copy constructor,
a deleted copy assignment operator,
and a trivial destructor.
They shall each support aggregate initialization syntax.
</blockquote>

<h3>29.3.2 Address Type [atomics.types.address]</h3>

<p>
For issue 845,
within the synopsis edit as follows.
</p>

<blockquote><pre><code>
....
typedef struct atomic_address {
....
  constexpr <del>explicit</del> atomic_address(void*);
....
</code></pre></blockquote>

<p>
For issue 845,
edit paragraph 1 as follows.
</p>

<blockquote>
The type <code>atomic_address</code> shall have standard layout.
It shall have a trivial default constructor,
a constexpr <del>explicit</del> value constructor,
a deleted copy constructor,
a deleted copy assignment operator,
and a trivial destructor.
It shall support aggregate initialization syntax.
</blockquote>

<h3>29.3.3 Generic Types [atomics.types.generic]</h3>

<p>
For issue 845,
within the synopsis edit as follows.
</p>

<blockquote><pre><code>
....
template &lt;class T&gt; struct atomic {
....
  constexpr <del>explicit</del> atomic(T);
....
template &lt;&gt; struct atomic&lt;<var>integral</var>&gt; : atomic_<var>itype</var> {
....
  constexpr <del>explicit</del> atomic(<var>integral</var>);
....
template &lt;&gt; struct atomic&lt;T*&gt; : atomic_address {
....
  constexpr <del>explicit</del> atomic(T*);
....
</code></pre></blockquote>

<p>
For issue 845,
edit paragraph 2 as follows.
</p>

<blockquote>
Specializations of the <code>atomic</code> template
shall have a deleted copy constructor,
a deleted copy assignment operator,
and a constexpr <del>explicit</del> value constructor.
</blockquote>

<h3>29.4 Operations on Types [atomics.types.operations]</h3>

<p>
For issue LWG 846,
before the description of ...<code>is_lock_free</code>,
that is before paragraph 4,
add the following description.
</p>

<blockquote>
<pre><code>
constexpr <var>A</var>::<var>A</var>(<var>C</var> desired);
</code></pre>
<dl>
<dt><i>Effects:</i></dt>
<dd>
Initializes the object with the value <code>desired</code>.
[<i>Note:</i>
Construction is not atomic.
&mdash;<i>end note</i>]
</dd>
</dl>
</blockquote>

</body>
</html>
