Boost logo

Boost-Commit :

From: bdawes_at_[hidden]
Date: 2007-11-12 14:06:05

Author: bemandawes
Date: 2007-11-12 14:06:05 EST (Mon, 12 Nov 2007)
New Revision: 41041

Supply relative vs absolute time rationale, with special case for condition variables.
Text files modified:
   sandbox/committee/LWG/thread_library.html | 33 ++++++++++++++++++++++++++++++++-
   1 files changed, 32 insertions(+), 1 deletions(-)

Modified: sandbox/committee/LWG/thread_library.html
--- sandbox/committee/LWG/thread_library.html (original)
+++ sandbox/committee/LWG/thread_library.html 2007-11-12 14:06:05 EST (Mon, 12 Nov 2007)
@@ -229,6 +229,13 @@
 &mdash;<i>end note</i>]
+Several functions described in this clause take an argument specifying
+a timeout. [<i>Note:</i> Reasonable use cases exist for both duration and
+absolute time based timeouts, so overloads for both are provided unless
+contraindicated. <i>--end note.</i>]
 <h3><a name="thread.threads">30.1 Threads [thread.threads]</a></h3>
@@ -2226,6 +2233,30 @@
 <h3><a name="thread.condition">30.3 Condition variables [thread.condition]</a></h3>
+[<i>Note:</i> For condition variables, time duration overloads are not provided because spurious wakeups
+would cause endless loops unless extraordinary care were taken. The composability
+of absolute time provides an equivalent, but terminating, idiom:
+<pre> mutex mut;
+ condition_variable cv;
+ ...
+ system_time abs_time = get_system_time() + seconds(1);
+ while (!pred())
+ cv.timed_wait(mut, abs_time);
+ if (pred()) ...</pre>
+Notice that changing the <code>time_wait</code> call to
+<code>cv.timed_wait(mut, get_system_time() + seconds(1));</code> to eliminate
+the <code>abs_time</code> variable could result in an endless loop.
+<i>--end note</i>]
 <strong>&lt;condition_variable&gt; synopsis</strong>
@@ -4797,4 +4828,4 @@
\ No newline at end of file

Boost-Commit list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at