<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 1459: Overlapping evaluations are allowed</title>
<meta property="og:title" content="Issue 1459: Overlapping evaluations are allowed">
<meta property="og:description" content="C++ library issue. Status: LEWG">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue1459.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#LEWG">LEWG</a> status.</em></p>
<h3 id="1459"><a href="lwg-active.html#1459">1459</a>. Overlapping evaluations are allowed</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#LEWG">LEWG</a>
 <b>Submitter:</b> Canada <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.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#LEWG">LEWG</a> status.</p>
<p><b>Duplicate of:</b> <a href="lwg-closed.html#1458" title="Overlapping evaluations are allowed (Status: Dup)">1458</a></p>
<p><b>Discussion:</b></p>
<p><b>Addresses CA-21, GB-131</b></p>
<p>
32.5.5 <a href="https://wg21.link/atomics.lockfree">[atomics.lockfree]</a> p.8 states:
</p>
<blockquote><p>
An atomic store shall only store a value that has
been computed from constants and program input values
by a finite sequence of program evaluations, such
that each evaluation observes the values of variables
as computed by the last prior assignment in the
sequence.
</p></blockquote>
<p>
... but 6.10.1 <a href="https://wg21.link/intro.execution">[intro.execution]</a> p.13 states:
</p>
<blockquote><p>
If A is not sequenced before B and B is not
sequenced before A, then A and B are unsequenced.
[ <em>Note</em>: The execution of unsequenced
evaluations can overlap. &mdash; <em>end note</em> ]
</p></blockquote>
<p>
Overlapping executions can make it impossible to
construct the sequence described in 32.5.5 <a href="https://wg21.link/atomics.lockfree">[atomics.lockfree]</a> p.8. We are not
sure of the intention here and do not offer a suggestion for
change, but note that 32.5.5 <a href="https://wg21.link/atomics.lockfree">[atomics.lockfree]</a> p.8 is the condition that prevents
out-of-thin-air reads.
</p>
<p>
For an example, suppose we have a function invocation
f(e1,e2). The evaluations of e1 and e2 can overlap.
Suppose that the evaluation of e1 writes y and reads x
whereas the evaluation of e2 reads y and writes x, with
reads-from edges as below (all this is within a single
thread).
</p>
<pre>
 e1           e2
Wrlx y--   --Wrlx x
      rf\ /rf
         X
        / \
Rrlx x&lt;-   -&gt;Rrlx y
</pre>
<p>
This seems like it should be allowed, but there seems to
be no way to produce a sequence of evaluations with the
property above.
</p>
<p>
In more detail, here the two evaluations, e1 and e2, are
being executed as the arguments of a function and are
consequently not sequenced-before each other. In
practice we'd expect that they could overlap (as allowed
by 6.10.1 <a href="https://wg21.link/intro.execution">[intro.execution]</a> p.13), with the two writes taking effect before the two
reads. However, if we have to construct a linear order of
evaluations, as in 32.5.5 <a href="https://wg21.link/atomics.lockfree">[atomics.lockfree]</a> p.8, then the execution above is not
permited. Is that really intended?
</p>

<p><i>[
Resolution proposed by ballot comment
]</i></p>

<p>
Please clarify.
</p>

<p><i>[2011-03-09 Hans comments:]</i></p>


<p>I'm not proud of 32.5.4 <a href="https://wg21.link/atomics.order">[atomics.order]</a> p9 (formerly p8), and I agree with the comments that this
isn't entirely satisfactory. 32.5.4 <a href="https://wg21.link/atomics.order">[atomics.order]</a> p9 was designed to preclude
out-of-thin-air results for races among <code>memory_order_relaxed</code> atomics, in spite of 
the fact that Java experience has shown we don't really know how to do that adequately. In 
the long run, we probably want to revisit this.
<p/>
However, in the short term, I'm still inclined to declare this NAD, for two separate reasons:
</p>

<ol>
<li><p>6.10.1 <a href="https://wg21.link/intro.execution">[intro.execution]</a> p15 states: "If a side effect on a scalar
object is unsequenced relative to either another side
effect on the same scalar object or a value computation
using the value of the same scalar object, the behavior is undefined."
I think the examples presented here have undefined behavior as a result.
It's not completely clear to me whether examples can be constructed
that exhibit this problem, and don't have undefined behavior.</p></li>

<li><p>This comment seems to be using a different meaning of "evaluation"
from what is used elsewhere in the standard. The sequence of evaluations
here doesn't have to consist of full expression evaluations.  They
can be evaluations of operations like lvalue to rvalue conversion,
or individual assignments. In particular, the reads and writes
executed by <code>e1</code> and <code>e2</code> in the example could be treated as separate
evaluations for purposes of producing the sequence.
The definition of "sequenced before" in 6.10.1 <a href="https://wg21.link/intro.execution">[intro.execution]</a> makes
little sense if the term "evaluation" is restricted to any notion
of complete expression. Perhaps we should add yet another note
to clarify this?  32.5.4 <a href="https://wg21.link/atomics.order">[atomics.order]</a> p10 probably leads to 
the wrong impression here.
<p/>
An alternative resolution would be to simply delete our flakey
attempt at preventing out-of-thin-air reads, by removing 32.5.4 <a href="https://wg21.link/atomics.order">[atomics.order]</a> p9-11,
possibly adding a note that explains that we technically allow,
but strongly discourage them. If we were starting this from scratch
now, that would probably be my preference.  But it seems like too drastic
a resolution at this stage.
</p></li>
</ol>

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

<p>
Moved to NAD Future
</p>



<p id="res-1459"><b>Proposed resolution:</b></p>





</body>
</html>
