<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <title>N2969: Background for issue 887: Clocks and Condition Variables</title>
  </head>

  <body>
<table>
  <tr>
    <td align="left">Document Number:</td>
    <td align="left">N2969=09-0159</td>
  </tr>
  <tr>
    <td align="left">Date:</td>
    <td align="left">2009-09-27</td>
  </tr>
  <tr>
    <td align="left">Project:</td>
    <td align="left">Programming Language C++</td>
  </tr>
</table>
<p>
Detlef Vollmann &lt;<a href="mailto:dv@vollmann.ch">dv@vollmann.ch</a>&gt;<br>
</p>
<h1>N2969: Background for issue 887: Clocks and Condition Variables</h1>
<p>
Timeliness of the return of any waiting functions is a big concern
in real-time environments.  It's clear that anything that's not
non-interruptible can have delays, the return of waiting functions
will always be late.
That doesn't mean that they can be arbitrarily late, even if an API
specification doesn't give any specific upper limit on those delays.
</p>
<p>
Especially for embedded systems, the environment is often controlled
very closely and these delays are measured as latency, and often the
whole system is built around this latency.
This latency can be some microseconds, some milliseconds or even some seconds,
and the system is generally tuned such that some external requirements on
the maximum latency are met.
</p>
<p>
So on a system with a maximum latency of e.g. 500ms, if a wait function
returns 450ms later than specified in the wait call, that is ok.
But if it returns half a week later, then that's a clear bug of the
implementation, especially if the rest of the system continues normally.
So being 40&micro;s late or 700ms late is a QOI issue, but being arbitrarly
late is simply a wrong implementation.
</p>
<p>
POSIX provides the function <code>pthread_cond_timedwait</code>
to wait on a condition variable with a timeout.
This timeout is measured by a predefined clock.
This predefined clock
can be set before a condition variable is initialized with the
function <code>pthread_condattr_setclock</code>, but this function
is not generally available on POSIX systems, but is part of the
<strong>ADVANCED REALTIME</strong> option of POSIX.
On all other POSIX systems, the timeout of <code>pthread_cond_timedwait</code>
is always an absolute time and measured on the standard (non-monotonic)
system clock.
</p>
<p>
So the <code>wait_*</code> in [thread.condition.condvar] as currently
specified can not correctly be implemented on top of POSIX condition variables.
The only function that can be correctly be implemented is
<code>wait_until</code> where <code>Clock == chrono::system_clock</code>.
</p>
<p>
That doesn't mean that these functions as specified can not be correctly
implemented on top of POSIX systems, but only by not using POSIX
condition variables, but instead providing an own implementation
of condition variables.
This is what implementations on Windows have to do anyway, because
Windows doesn't have condition variables.
But given the history of implementing condition variables on Windows
(see <a href="http://sources.redhat.com/ml/pthreads-win32/2001/msg00012.html">
http://sources.redhat.com/ml/pthreads-win32/2001/msg00012.html</a>)
this borders on "heroic effort" that should not be required.
And also most users of C++ condition variables on POSIX systems
expect them to be identical to the native condition variables,
and that their implementers provide them some mechanism to get
a native handle.
</p>

<h3>Proposed resolution</h3>
<p>
Remove <code>wait_for</code> functions from [thread.condition.condvar].
</p>
<p>
Specify <code>wait_until</code> only for
<code>Clock == chrono::system_clock</code>.
</p>
  </body>
</html>
