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

From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2007-10-18 08:57:20

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