Re: [boost] Boost Threads Condition may block forever on clockchange

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2007-12-07 03:52:55

Alexander Terekhov <terekhov <at> web.de> writes:

> Anthony Williams wrote:
> > 
> > Alexander Terekhov <terekhov <at> web.de> writes:
> > > Anthony Williams wrote:
> > > [...]
> > > > Waitable timers. According to the docs, when you specify an absolute
> > > > timeout
> > > > for a timer it tracks clock changes.
> > >
> > > That isn't really helpful given that win32 waitable timers don't
> > > synchronize with condvar waiters by locking associated mutexes.
> > 
> > The point is that a condvar waiter doing a timed wait can use the waitable
> > timer
> > as part of a WaitForMultipleObjects call waiting on the sync objects 
> > internal to
> > the cond var, rather than using a timeout: if the waitable timer is 
> > triggered
> > then the specified absolute time has been reached, and the call has timed 
> > out.
> > 
> > Of course, the condvar implementation then needs to handle relocking the
> > mutexes.
> 
> I meant the race between clock change and "WaitForMultipleObjects 
> call waiting".

Here's the flow as it stands at the moment:

1. User calls timed_wait with an absolute time
2. Thread added to waiter list and external mutex unlocked
3. Waitable timer configured for specified absolute time
4. Thread waits for internal notify or timer expiry
5a. if timer expired we're done: relock external mutex
5b. if we were notified, check if it was really us: if so, we're done: relock
external mutex
6. If we didn't time out, and the notify wasn't us, loop to 3.

Since the waitable timer is tied to the system clock time, the only "race" is if
the clock is changed before the timer is configured in step 3. I believe the
only issue is if the clock changes multiple times in quick succession. If, for
example, the clock is changed back and then forward again, then the timer may or
may not expire depending on whether it was configured before or after the
forward change.

There is no race with WaitForMultipleObjects, as the timer is tied to the system
clock. If the timer has expired by the time we wait, then we time out 
immediately.

It might be better to configure the timer once rather than multiple times, but
that's not a big deal.

Anthony