Boost.Threads thoughts on timed waits

From: williamkempf_at_[hidden]
Date: 2001-05-23 10:40:34

I was originally under the impression that timed waits should be 
handled using "durations" mostly because of my biases from using 
Win32 threads.  The pthread libraries have a timed wait only for 
condition variables where a "time period" is used instead of 
a "duration".  (In case you don't understand this a "duration" means 
to wait a given amount of time (represented in milliseconds for Win32 
threads) while a "time period" means to wait until a specific period 
in time arrives.)  I didn't agree with this approach because you 
typically want to "time out" after so much time has elapsed, not when 
a specific time is reached.  With the pthread approach you wind up 
having to get the current time and calculate a time from that and the 
duration in which you want to wait.  This seemed like a lot of work 
just to wait say half a second.

I've been reading on this subject from the book "Programming with 
POSIX Threads" by David R. Butenhof and have changed my mind at least 
for waits on condition variables.  A wait on a condition variable is 
subject to "spurios wakeups" and therefore needs to be wrapped in a 
loop that continuously checks the predicate.  With a "duration" wait 
you'd need to continuously recalculate the duration in each iteration 
of the loop.  This is complicated, slow, and not as accurate on some 
platforms.  It's simply easier (and probably better) to use a "time 
period" wait instead, which is calculated only before entering the 
loop, not on each iteration.

So, I've changed my mind at least in regards to 
boost::condition::timed_wait.  However, the other timed operations 
(boost::semaphore::down and all mutex timedlock types) aren't subject 
to spurious wakeups so the simplest usage would be to 
retain "duration" timeouts for these.  However, this brings up the 
question of consistency.

What are people's thoughts on this subject?

Bill Kempf