<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 859: Monotonic Clock is Conditionally Supported?</title>
<meta property="og:title" content="Issue 859: Monotonic Clock is Conditionally Supported?">
<meta property="og:description" content="C++ library issue. Status: C++11">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue859.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="859"><a href="lwg-defects.html#859">859</a>. Monotonic Clock is Conditionally Supported?</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++11">C++11</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2008-06-23 <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++11">C++11</a> status.</p>
<p><b>Discussion:</b></p>

<p>Related to <a href="lwg-defects.html#958" title="Various threading bugs #8 (Status: Resolved)">958</a><sup><a href="https://cplusplus.github.io/LWG/issue958" title="Latest snapshot">(i)</a></sup>, <a href="lwg-closed.html#959" title="Various threading bugs #9 (Status: NAD)">959</a><sup><a href="https://cplusplus.github.io/LWG/issue959" title="Latest snapshot">(i)</a></sup>.</p>

<p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.htm">N2661</a>
says that there is a class named <code>monotonic_clock</code>. It also says that this
name may be a synonym for <code>system_clock</code>, and that it's conditionally
supported. So the actual requirement is that it can be monotonic or not,
and you can tell by looking at <code>is_monotonic</code>, or it might not exist at
all (since it's conditionally supported). Okay, maybe too much
flexibility, but so be it.
</p>
<p>
A problem comes up in the threading specification, where several
variants of <code>wait_for</code> explicitly use <code>monotonic_clock::now()</code>. What is the
meaning of an effects clause that says
</p>

<blockquote><pre>
wait_until(lock, chrono::monotonic_clock::now() + rel_time)
</pre></blockquote>

<p>
when <code>monotonic_clock</code> is not required to exist?
</p>

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


<blockquote>
<p>
Nick: maybe instead of saying that <code>chrono::monotonic_clock</code> is
conditionally supported, we could say that it's always there, but not
necessarily supported..
</p>
<p>
Beman: I'd prefer a typedef that identifies the best clock to use for
<code>wait_for</code> locks.
</p>
<p>
Tom: combine the two concepts; create a duration clock type, but keep
the is_monotonic test.
</p>
<p>
Howard: if we create a <code>duration_clock</code> type, is it a typedef or an
entirely true type?
</p>
<p>
There was broad preference for a typedef.
</p>
<p>
Move to Open. Howard to provide wording to add a typedef for
duration_clock and to replace all uses of monotonic_clock in function
calls and signatures with duration_clock.
</p>
</blockquote>

<p><i>[
Howard notes post-San Francisco:
]</i></p>


<blockquote>
<p>
After further thought I do not believe that creating a <code>duration_clock typedef</code>
is the best way to proceed.  An implementation may not need to use a
<code>time_point</code> to implement the <code>wait_for</code> functions.
</p>

<p>
For example, on POSIX systems <code>sleep_for</code> can be implemented in terms of
<code>nanosleep</code> which takes only a duration in terms of nanoseconds.  The current
working paper does not describe <code>sleep_for</code> in terms of <code>sleep_until</code>.
And paragraph 2 of 32.2.4 <a href="https://wg21.link/thread.req.timing">[thread.req.timing]</a> has the words strongly encouraging
implementations to use monotonic clocks for <code>sleep_for</code>:
</p>

<blockquote><p>
2 The member functions whose names end in <code>_for</code> take an argument that
specifies a relative time. Implementations should use a monotonic clock to
measure time for these functions.
</p></blockquote>

<p>
I believe the approach taken in describing the effects of <code>sleep_for</code>
and <code>try_lock_for</code> is also appropriate for <code>wait_for</code>.  I.e. these
are not described in terms of their <code>_until</code> variants.
</p>

</blockquote>

<p><i>[
2009-07 Frankfurt:
]</i></p>


<blockquote>
<p>
Beman will send some suggested wording changes to Howard.
</p>
<p>
Move to Ready.
</p>
</blockquote>

<p><i>[
2009-07-21 Beman added the requested wording changes to <a href="lwg-defects.html#962" title="Various threading bugs #12 (Status: C++11)">962</a><sup><a href="https://cplusplus.github.io/LWG/issue962" title="Latest snapshot">(i)</a></sup>.
]</i></p>




<p id="res-859"><b>Proposed resolution:</b></p>
<p>
Change 32.7.4 <a href="https://wg21.link/thread.condition.condvar">[thread.condition.condvar]</a>, p21-22:
</p>

<blockquote>
<pre>
template &lt;class Rep, class Period&gt; 
  bool wait_for(unique_lock&lt;mutex&gt;&amp; lock, 
                const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
</pre>
<blockquote>
<p><ins>
<i>Precondition:</i> <code>lock</code> is locked by the calling thread, and either
</ins></p>
<ul>
<li><ins>no other thread is waiting on this <code>condition_variable</code> object or</ins></li>
<li><ins><code>lock.mutex()</code> returns the same value for each of the <code>lock</code>
arguments supplied by all concurrently waiting threads (via <code>wait</code>,
<code>wait_for</code> or <code>wait_until</code>).</ins></li>
</ul>
<p>
21 <i>Effects:</i>
</p>
<blockquote><pre>
<del>wait_until(lock, chrono::monotonic_clock::now() + rel_time)</del>
</pre></blockquote>
<ul>
<li><ins>
Atomically calls <code>lock.unlock()</code> and blocks on <code>*this</code>.
</ins></li>

<li><ins>
When unblocked, calls <code>lock.lock()</code> (possibly blocking on the lock) and returns.
</ins></li>

<li><ins>
The function will unblock when signaled by a call to <code>notify_one()</code>, a call
to <code>notify_all()</code>, by 
the elapsed time <code>rel_time</code> passing (32.2.4 <a href="https://wg21.link/thread.req.timing">[thread.req.timing]</a>),
or spuriously.
</ins></li>

<li><ins>
If the function exits via an exception, <code>lock.unlock()</code> shall be called 
prior to exiting the function scope.
</ins></li>
</ul>

<p><ins>
<i>Postcondition:</i> <code>lock</code> is locked by the calling thread.
</ins></p>


<p>
22 <i>Returns:</i> <code>false</code> if the call is returning because the time
duration specified by <code>rel_time</code> has elapsed, otherwise <code>true</code>.
</p>

<p><i>[
This part of the wording may conflict with <a href="lwg-defects.html#857" title="condition_variable::time_wait return bool error prone (Status: C++11)">857</a><sup><a href="https://cplusplus.github.io/LWG/issue857" title="Latest snapshot">(i)</a></sup> in detail, but does
not do so in spirit.  If both issues are accepted, there is a logical merge.
]</i></p>


<p><ins>
<i>Throws:</i> <code>std::system_error</code> when the effects or postcondition cannot be achieved.
</ins></p>

<p><ins>
<i>Error conditions:</i>
</ins></p>

<ul>
<li><ins>
<code>operation_not_permitted</code> -- if the thread does not own the lock.
</ins></li>
<li><ins>
equivalent error condition from <code>lock.lock()</code> or <code>lock.unlock()</code>.
</ins></li>
</ul>

</blockquote>
</blockquote>

<p>
Change 32.7.4 <a href="https://wg21.link/thread.condition.condvar">[thread.condition.condvar]</a>, p26-p29:
</p>

<blockquote>
<pre>
template &lt;class Rep, class Period, class Predicate&gt; 
  bool wait_for(unique_lock&lt;mutex&gt;&amp; lock, 
                const chrono::duration&lt;Rep, Period&gt;&amp; rel_time, 
                Predicate pred);
</pre>
<blockquote>
<p><ins>
<i>Precondition:</i> <code>lock</code> is locked by the calling thread, and either
</ins></p>
<ul>
<li><ins>no other thread is waiting on this <code>condition_variable</code> object or</ins></li>
<li><ins><code>lock.mutex()</code> returns the same value for each of the <code>lock</code>
arguments supplied by all concurrently waiting threads (via <code>wait</code>,
<code>wait_for</code> or <code>wait_until</code>).</ins></li>
</ul>
<p>
<i>26 Effects:</i>
</p>
<blockquote><pre>
<del>wait_until(lock, chrono::monotonic_clock::now() + rel_time, std::move(pred))</del>
</pre>
<ul>
<li><ins>
Executes a loop:  Within the loop the function first evaluates <code>pred()</code>
and exits the loop if the result of <code>pred()</code> is <code>true</code>.
</ins></li>
<li><ins>
Atomically calls <code>lock.unlock()</code>
and blocks on <code>*this</code>.
</ins></li>
<li><ins>
When unblocked, calls <code>lock.lock()</code> (possibly blocking on the lock).
</ins></li>
<li><ins>
The function will unblock when signaled by a call to <code>notify_one()</code>, a
call to <code>notify_all()</code>, by the elapsed time <code>rel_time</code> passing (30.1.4
[thread.req.timing]), or spuriously.
</ins></li>
<li><ins>
If the function exits via an exception, <code>lock.unlock()</code> shall be called
prior to exiting the function scope.
</ins></li>
<li><ins>
The loop terminates when <code>pred()</code> returns <code>true</code> or when the time
duration specified by <code>rel_time</code> has elapsed.
</ins></li>
</ul>
</blockquote>

<p>
27 [<i>Note:</i> There is no blocking if <code>pred()</code> is initially <code>true</code>,
even if the timeout has already expired. <i>-- end note</i>]
</p>

<p><ins>
<i>Postcondition:</i> <code>lock</code> is locked by the calling thread.
</ins></p>

<p>
28 <i>Returns:</i> <code>pred()</code>
</p>

<p>
29 [<i>Note:</i> The returned value indicates whether the predicate evaluates to
<code>true</code> regardless of whether the timeout was triggered. <i>-- end note</i>]
</p>

<p><ins>
<i>Throws:</i> <code>std::system_error</code> when the effects or postcondition cannot be achieved.
</ins></p>

<p><ins>
<i>Error conditions:</i>
</ins></p>

<ul>
<li><ins>
<code>operation_not_permitted</code> -- if the thread does not own the lock.
</ins></li>
<li><ins>
equivalent error condition from <code>lock.lock()</code> or <code>lock.unlock()</code>.
</ins></li>
</ul>

</blockquote>
</blockquote>

<p>
Change 32.7.5 <a href="https://wg21.link/thread.condition.condvarany">[thread.condition.condvarany]</a>, p18-19:
</p>

<blockquote>
<pre>
template &lt;class Lock, class Rep, class Period&gt; 
  bool wait_for(Lock&amp; lock, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
</pre>
<blockquote>
<p>
18 <i>Effects:</i>
</p>
<blockquote><pre>
<del>wait_until(lock, chrono::monotonic_clock::now() + rel_time)</del>
</pre></blockquote>

<ul>
<li><ins>
Atomically calls <code>lock.unlock()</code> and blocks on <code>*this</code>.
</ins></li>

<li><ins>
When unblocked, calls <code>lock.lock()</code> (possibly blocking on the lock) and returns.
</ins></li>

<li><ins>
The function will unblock when signaled by a call to <code>notify_one()</code>, a call to
<code>notify_all()</code>, by
the elapsed time <code>rel_time</code> passing (32.2.4 <a href="https://wg21.link/thread.req.timing">[thread.req.timing]</a>),
or spuriously.
</ins></li>

<li><ins>
If the function exits via an exception, <code>lock.unlock()</code> shall be called
prior to exiting the function scope.
</ins></li>
</ul>

<p><ins>
<i>Postcondition:</i> <code>lock</code> is locked by the calling thread.
</ins></p>

<p>
19 <i>Returns:</i> <code>false</code> if the call is returning because the time duration
specified by <code>rel_time</code> has elapsed, otherwise <code>true</code>.
</p>

<p><ins>
<i>Throws:</i> <code>std::system_error</code> when the returned value, effects,
or postcondition cannot be achieved.
</ins></p>

<p><ins>
<i>Error conditions:</i>
</ins></p>

<ul>
<li><ins>
equivalent error condition from <code>lock.lock()</code> or <code>lock.unlock()</code>.
</ins></li>
</ul>
</blockquote>
</blockquote>

<p>
Change 32.7.5 <a href="https://wg21.link/thread.condition.condvarany">[thread.condition.condvarany]</a>, p23-p26:
</p>

<blockquote>
<pre>
template &lt;class Lock, class Rep, class Period, class Predicate&gt; 
  bool wait_for(Lock&amp; lock, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time, Predicate pred);
</pre>
<blockquote>
<p><ins>
<i>Precondition:</i> <code>lock</code> is locked by the calling thread, and either
</ins></p>
<ul>
<li><ins>no other thread is waiting on this <code>condition_variable</code> object or</ins></li>
<li><ins><code>lock.mutex()</code> returns the same value for each of the <code>lock</code>
arguments supplied by all concurrently waiting threads (via <code>wait</code>,
<code>wait_for</code> or <code>wait_until</code>).</ins></li>
</ul>
<p>
<i>23 Effects:</i>
</p>
<blockquote><pre>
<del>wait_until(lock, chrono::monotonic_clock::now() + rel_time, std::move(pred))</del>
</pre>
<ul>
<li><ins>
Executes a loop:  Within the loop the function first evaluates <code>pred()</code>
and exits the loop if the result of <code>pred()</code> is <code>true</code>.
</ins></li>
<li><ins>
Atomically calls <code>lock.unlock()</code>
and blocks on <code>*this</code>.
</ins></li>
<li><ins>
When unblocked, calls <code>lock.lock()</code> (possibly blocking on the lock).
</ins></li>
<li><ins>
The function will unblock when signaled by a call to <code>notify_one()</code>, a
call to <code>notify_all()</code>, by the elapsed time <code>rel_time</code> passing (30.1.4
[thread.req.timing]), or spuriously.
</ins></li>
<li><ins>
If the function exits via an exception, <code>lock.unlock()</code> shall be called
prior to exiting the function scope.
</ins></li>
<li><ins>
The loop terminates when <code>pred()</code> returns <code>true</code> or when the time
duration specified by <code>rel_time</code> has elapsed.
</ins></li>
</ul>
</blockquote>

<p>
24 [<i>Note:</i> There is no blocking if <code>pred()</code> is initially <code>true</code>,
even if the timeout has already expired. <i>-- end note</i>]
</p>

<p><ins>
<i>Postcondition:</i> <code>lock</code> is locked by the calling thread.
</ins></p>

<p>
25 <i>Returns:</i> <code>pred()</code>
</p>

<p>
26 [<i>Note:</i> The returned value indicates whether the predicate evaluates to
<code>true</code> regardless of whether the timeout was triggered. <i>-- end note</i>]
</p>

<p><ins>
<i>Throws:</i> <code>std::system_error</code> when the effects or postcondition cannot be achieved.
</ins></p>

<p><ins>
<i>Error conditions:</i>
</ins></p>

<ul>
<li><ins>
<code>operation_not_permitted</code> -- if the thread does not own the lock.
</ins></li>
<li><ins>
equivalent error condition from <code>lock.lock()</code> or <code>lock.unlock()</code>.
</ins></li>
</ul>

</blockquote>
</blockquote>







</body>
</html>
