Boost logo

Boost :

From: Jeff Garland (jeff_at_[hidden])
Date: 2007-10-18 10:17:18

catching up with a couple messages:

Johan Nilsson wrote:
> > n2320 calls for interfaces with time_duration on all timed_lock
> > functions.

> What about sleep?

There is a relative time sleep function:

namespace std {
   namespace this_thread {

     template <class ElapsedTime>
         void sleep(const ElapsedTime& rel_t);

Peter Dimov wrote:
> Johan Nilsson wrote:
>> Peter Dimov wrote:
>>> Johan Nilsson wrote:
>>>> It's possible to handle spurious wakeups with relative times as
>>>> well, perhaps just not perfectly (depending on underlying platform
>>>> support). If
>>>> the only way to perform a timed wait on a condition variable is by
>>>> an absolute time, I believe the most common usage will be something
>>>> like this (pseudocode):
>>>> ---
>>>> time now = microsec_clock::local_time();
>>>> time timeout = now + milliseconds(250);
>>>> if (!cv.timed_wait(lk, timeout, my_pred()))
>>>> {
>>>> throw "Timed out!";
>>>> }
>>> You are missing a loop.
>> I think you're missing the predicate "my_pred()".
> You are right, I was. Relative timeouts do indeed make sense for the
> predicate version, if (1) you are willing to accept the inconsistency and
> (2) you are only concerned with use cases like the above where the timeout
> is not a deadline but a safety net.
> An additional relative timeout overload in the cases where it's appropriate
> could work, but the current templatization does not allow it unless concepts
> come into play.

n2320 proposal includes both relative and absolute timeouts for the condition
variables. As you can imagine, if the client writes the loop, instead of
using the predicate form, having an absolute time overload simplifies the
code. There's another subtle issue as well. You want to use the same clock
implementation for measuring these...which is part of the justification for


Boost list run by bdawes at, gregod at, cpdaniel at, john at