Boost logo

Boost :

From: Pete Becker (petebecker_at_[hidden])
Date: 2002-07-01 09:00:37

At 06:55 AM 7/1/2002 -0500, William Kempf wrote:
>>From: "Simon J. Julier" <sjulier_at_[hidden]>
>>1. The Windows system timer runs between 10ms and 55ms, depending on the
>>version of Windows used
>>me_5h2d.asp). Reinhold tells me that the value returned by
>>GetSystemTimeAsFileTime seems to update at the same rate.
>This one I consider a non-issue. The xtime stuff does not promise any
>kind of granularity, so a 10-55ms variation on different Windows platforms
>is not a "violation" of the implied contract here.

It's not a problem for xtime itself, but it is a problem for the
implementation of a couple of things. I just spent the weekend identifying
it, and was about to send you an e-mail.

xtime target;
xtime_get(&target, TIME_UTC);
target.nsec += 200000;
xtime now;
xtime_get(&now, TIME_UTC);
assert(target.sec < now.sec || target.sec == now.sec && target.nsec <=

The problem is that under Win32 the implemtenation of thread::sleep
reconstructs the time difference between now and the target time, and
converts it to milliseconds in order to call Sleep. So in this example,
200000 nanoseconds gets converted to 1 ms, and the sleep call delays for 1
ms. With a clock tick rate of 10 ms, though, nine times out of ten the
assert will trigger because the xtime clock didn't tick during the sleep.
The same thing occurs whenever the number of milliseconds requested isn't
an exact multiple of the xtime clock tick rate. Ideally, thread::sleep
would the number of milliseconds up to the next higher tick boundary, but
that boundary isn't generally known. So the solution is to write a loop in

while current time < target time
         Sleep until target time

Hardware folks call this problem "jitter."

This is also potentially a problem for condition::timed_wait and

        -- Pete

Dinkumware, Ltd.
"Genuine Software"

Boost list run by bdawes at, gregod at, cpdaniel at, john at