Johan Nilsson:
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).
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.