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.
I believe there are "relative" deadlines as well. Suppose you are receiving data that should arrive at a certain frequency; if that frequency is e.g. 20Hz, a reasonable value for emitting a data timeout warning could be 2 periods => 50*2 = 100ms (in this case, a background thread would put each data item in a common buffer when it arrives, and signal the cv for some other entity to process it). Sure, there're no guarantees that this will always work correctly on a "soft" realtime system - but in general this is perfectly reasonable (and acceptable) for many applications. Especially for in-house applications that run on computers dedicated for a specific purpose.
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.
Well, where would it not be appropriate? / Johan