From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-10-18 12:56:13
> I believe there are "relative" deadlines as well. Suppose you are
> 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).
You may well start out with a relative timeout value, but it's converted to
an absolute deadline just once, at the start, on a high level that doesn't
usually deal with thread primitives. Then you propagate the absolute
deadline through code. Something like:
bool f( abstime const & dl )
return g( dl ) && h( dl );
(guaranteed wait-free rollback on failed h omitted for simplicity :-) ).
Even for the simple condvar wait case, you have a preceding mutex lock which
needs to also respect the deadline.
Relative timeouts on the primitive level are typically coarse (without a
specific correct value) and usually meant to catch deadlocks.
Side note: to support the deadline use case, all timed operations have to
include an overload taking an absolute value.
>> 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?
I think that the non-predicate version of condition::timed_wait should not
allow a relative timeout since this would make it even more error-prone than
it is now.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk