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

From: Jeff Garland (jeff_at_[hidden])
Date: 2007-10-18 10:17:18

catching up with a couple messages:

Johan Nilsson wrote:
 > > n2320 calls for interfaces with time_duration on all timed_lock
 > > functions.

 > What about sleep?

There is a relative time sleep function:

namespace std {
   namespace this_thread {

     template <class ElapsedTime>
         void sleep(const ElapsedTime& rel_t);
   }
}

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.
> 
> 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. 

n2320 proposal includes both relative and absolute timeouts for the condition 
variables.  As you can imagine, if the client writes the loop, instead of 
using the predicate form, having an absolute time overload simplifies the 
code.  There's another subtle issue as well.  You want to use the same clock 
implementation for measuring these...which is part of the justification for 
system_time.

Jeff