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

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2007-11-26 02:52:05

 <ak1mbox-boost <at> yahoo.ca> writes:

> I've noticed a strange change in behaviour when
> condition is called with xtime parameter,
> condition::timed_wait. If right after the condition is
> called the clock is moved back the code never exits
> from condition unless signalled, even moving the clock
> back forward did not seem to fix the problem. The test
> was done on Windows XP. 
> 
> Is this desired behaviour or a bug? It seems strange
> that the condition is based on the current time and
> not just on a time offset.
> 
> Any help with resolving this would be really
> appreciated.

The implementation uses an absolute time internally, since absolute times are
composable --- though the win32 API calls are made with a timeout in
milliseconds, it is the number of milliseconds until the supplied absolute time.
This allows for multiple win32 API calls without having to work out how much of
the timeout has elapsed --- this is done implicitly by the calculation of the
number of milliseconds remaining.

Ideally we would have a monotonically increasing timer which is independent of
the system clock. Unfortunately, we don't have such a timer --- we have to rely
on the system's idea of UTC time. If the clock is set back after the timeout for
the wait has been chosen, but before the number of milliseconds to wait in a
win32 API call has been calculated, the number of milliseconds will be rather
large.

Anthony