Re: [boost] [thread] Questions/concerns about recentthreadlibchanges

From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-10-18 12:56:13

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.