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

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2007-11-30 17:31:12

Johan Nilsson <r.johan.nilsson <at> gmail.com> writes:

> Anthony Williams wrote:
> > As far as I can gather, POSIX expects the latter. Windows only offers
> > relative timeouts, so we get the former, though there's a potential
> > race between calculating "now" vs changing the clock. If I had a
> > reliable way to abort a wait if the clock changed.
> 
> For Windows: As you said yourself earlier, WM_TIMECHANGE is available. 
> Create a hidden window and run the message loop in a worker thread to catch 
> those msgs. This could presumably be implemented using some kind of lazy 
> init to work transparently even for the DLL version of Boost.Thread.

It appears that the win32 API does provide a solution for this after all:
Waitable timers. According to the docs, when you specify an absolute timeout
for a timer it tracks clock changes.

I've checked in a new version that uses these where available. Since the
resolution of waitable timers is only about 10ms, if the wait is less than
20ms then that a simple relative wait is used (even if the initial target was
absolute).

At the moment, this is only done for the interruptible waits (sleep and
condition::timed_wait), but a similar scheme could be used for all timed waits
(e.g. mutex timed lock).

Anthony