<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 1478: Clarify race conditions in atomics initialization</title>
<meta property="og:title" content="Issue 1478: Clarify race conditions in atomics initialization">
<meta property="og:description" content="C++ library issue. Status: C++11">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue1478.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#C++11">C++11</a> status.</em></p>
<h3 id="1478"><a href="lwg-defects.html#1478">1478</a>. Clarify race conditions in atomics initialization</h3>
<p><b>Section:</b> 32.5.8.2 <a href="https://wg21.link/atomics.types.operations">[atomics.types.operations]</a> <b>Status:</b> <a href="lwg-active.html#C++11">C++11</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <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.types.operations">active issues</a> in [atomics.types.operations].</p>
<p><b>View all other</b> <a href="lwg-index.html#atomics.types.operations">issues</a> in [atomics.types.operations].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#C++11">C++11</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-136</b></p>
<p>
GB requests normative clarification in 32.5.8.2 <a href="https://wg21.link/atomics.types.operations">[atomics.types.operations]</a> p.4 that
concurrent access constitutes a race, as already done on p.6 and p.7.
</p>
<p><i>[
Resolution proposed in ballot comment:
]</i></p>


<blockquote><p>
Initialisation of atomics:
<p/>
We believe the intent is that for any atomics there is a distinguished
initialisation write, but that this need not happens-before all the
other operations on that atomic - specifically so that the
initialisation write might be non-atomic and hence give rise to a data
race, and hence undefined behaviour, in examples such as this (from
Hans):
</p>
<blockquote><pre>
atomic&lt;atomic&lt;int&gt; *&gt; p
f()                      |
{ atomic&lt;int&gt;x;          | W_na x
  p.store(&amp;x,mo_rlx);    | W_rlx p=&amp;x
}                        |
</pre></blockquote><p>
(where na is nonatomic and rlx is relaxed). We suspect also that no
other mixed atomic/nonatomic access to the same location is intended
to be permitted. Either way, a note would probably help.
</p></blockquote>

<p><i>[2011-02-26: Hans comments and drafts wording]</i></p>


<p>I think the important point here is to clarify that races on atomics
are possible, and can be introduced as a result of non-atomic
initialization operations.  There are other parts of this that remain unclear
to me, such as whether there are other ways to introduce data races on atomics,
or whether the races with initialization also introduce undefined behavior
by the 3.8 lifetime rules.  But I don't think that it is necessary to resolve
those issues before releasing the standard.  That's particularly true
since we've introduced <code>atomic_init</code>, which allows easier ways to
construct initialization races.
</p>

<p><i>[2011-03 Madrid]</i></p>

<p>Accepted to be applied immediately to the WP</p>



<p id="res-1478"><b>Proposed resolution:</b></p>
<ol>
<li><p>Update 99 [atomics.types.operations.req] p. 5 as follows:</p>

<blockquote><pre>
constexpr A::A(C desired);
</pre><blockquote><p>
5 <i>Effects</i>: Initializes the object with the value <code>desired</code>. <del>[ <i>Note</i>: 
Construction is not atomic. &mdash; <i>end note</i> ]</del><ins> Initialization is not an 
atomic operation (1.10) [intro.multithread]. [<i>Note</i>: It is possible to have an
access to an atomic object <code>A</code> race with its construction, for example
by communicating the address of the just-constructed object <code>A</code> to another thread 
via <code>memory_order_relaxed</code> atomic operations on a suitable atomic pointer variable, 
and then immediately accessing <code>A</code> in the receiving thread.  This results in undefined 
behavior. &mdash; <i>end note</i>]</ins>
</p></blockquote></blockquote>
</li>

<li><p>In response to the editor comment to 99 [atomics.types.operations.req] p. 8: 
The first <i>Effects</i> element is the correct and intended one:</p>

<blockquote><pre>
void atomic_init(volatile A *object, C desired);
void atomic_init(A *object, C desired);
</pre><blockquote><p>
8 <i>Effects</i>: Non-atomically initializes <code>*object</code> with value <code>desired</code>.
This function shall only be applied to objects that have been default constructed, and then only once.
[ <i>Note</i>: these semantics ensure compatibility with C. &mdash; <i>end note</i> ] [ <i>Note</i>: 
Concurrent access from another thread, even via an atomic operation, constitutes a data 
race. &mdash; <i>end note</i> ] <del>[<i>Editor's note</i>: The preceding text is from the WD as 
amended by N3196. N3193 makes different changes, marked up in the paper as follows:]
<i>Effects</i>: Dynamically initializes an atomic variable. Non-atomically That is, non-atomically assigns the
value desired to <code>*object</code>. [ <i>Note</i>: this operation may need to initialize 
locks. &mdash; <i>end note</i> ] Concurrent access from another thread, even via an atomic 
operation, constitutes a data race.</del>
</p></blockquote></blockquote>
</li>
</ol>





</body>
</html>
