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 system_time. Jeff