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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk