<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 2190: Condition variable specification</title>
<meta property="og:title" content="Issue 2190: Condition variable specification">
<meta property="og:description" content="C++ library issue. Status: C++14">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue2190.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++14">C++14</a> status.</em></p>
<h3 id="2190"><a href="lwg-defects.html#2190">2190</a>. Condition variable specification</h3>
<p><b>Section:</b> 32.7 <a href="https://wg21.link/thread.condition">[thread.condition]</a> <b>Status:</b> <a href="lwg-active.html#C++14">C++14</a>
 <b>Submitter:</b> Hans Boehm <b>Opened:</b> 2012-09-25 <b>Last modified:</b> 2016-01-28</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="lwg-index.html#thread.condition">issues</a> in [thread.condition].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#C++14">C++14</a> status.</p>
<p><b>Discussion:</b></p>

<p>
The condition variable specification possibly leaves it unclear whether the effect of a <code>notify_one()</code> 
call can effectively be delayed, so that a call unblocks a <code>wait()</code> call that happens after the 
<code>notify_one</code> call. (For <code>notify_all()</code> this is not detectable, since it only results in spurious 
wake-ups.)  Although this may at first glance seem like a contrived interpretation, it gains relevance since 
glibc in fact allows the analogous behavior (see <a href="http://sourceware.org/bugzilla/show_bug.cgi?id=13165">here</a>) 
and it is currently controversial whether this is correct and the Posix specification allows it (see 
<a href="http://austingroupbugs.net/view.php?id=609">here</a>).
</p>
<p>
The following proposed resolution disallows the glibc implementation, remaining consistent with the believed intent of C++11.  
To make that clear, we require that the "unspecified total order" O from 32.7 <a href="https://wg21.link/thread.condition">[thread.condition]</a> p4 be 
consistent with <em>happens-before</em>.  We also intend that the 3 components of a wait occur in order in O, 
but stating that explicitly seems too pedantic.  Since they are numbered, it appears clear enough that they are 
sequenced one after the other.
</p>
<p>
Another uncertainty with the current phrasing is whether there is a single total order that includes all c.v. 
accesses, or one total order per c.v.  We believe it actually doesn't matter, because there is no way to tell the 
difference, but this requires a bit more thought.  We resolved it one way, just to remove the potential ambiguity.
</p>

<p><i>[2012, Portland: Move to Review]</i></p>

<p>
This is linked to a <a href="http://sourceware.org/bugzilla/show_bug.cgi?id=13165">glibc issue</a>, and
a <a href="http://austingroupbugs.net/view.php?id=609">POSIX specification issue</a>.
</p>

<p>
We believe the proposed wording fixes the ambiguity in C++ and is compatible with the proposed resolution
for Posix (which confirms the glibc behaviour as illegal).
</p>

<p>
Moved to review (Detlef hopes to send some improved wording to the reflector).
</p>

<p><i>[2013-04-20, Bristol]</i></p>

<p>Accepted for the working paper</p>



<p id="res-2190"><b>Proposed resolution:</b></p>
<p>This wording is relative to N3376.</p>

<ol>
<li><p>Change 32.7 <a href="https://wg21.link/thread.condition">[thread.condition]</a> p4 as indicated:</p>
<blockquote><p>
-4- The implementation shall behave as if <ins>all executions of</ins> <code>notify_one</code>, <code>notify_all</code>, 
and each part of the <code>wait</code>, <code>wait_for</code>, and <code>wait_until</code> executions are executed in 
<del>some</del><ins>a single</ins> unspecified total order <ins>consistent with the "happens before" order</ins>.
</p></blockquote>
</li>
</ol>





</body>
</html>
