Re: [boost] xtime and GetSystemTimeAsFileTime

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-07-01 09:31:25

----- Original Message -----
From: "Pete Becker" <petebecker_at_[hidden]>
To: <boost_at_[hidden]>; <boost_at_[hidden]>
Sent: Monday, July 01, 2002 9:00 AM
Subject: Re: [boost] xtime and GetSystemTimeAsFileTime

> 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
>
>>(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/
ti
> >>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;
> thread::sleep(target);
> xtime now;
> xtime_get(&now, TIME_UTC);
> assert(target.sec < now.sec || target.sec == now.sec && target.nsec <=
> now.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
> thread::sleep:
>
> 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
> scoped_timed_lock::timed_lock.

Ahh... an interesting artifact I hadn't considered.  A very corner case
kinda problem, but one that should be addressed.  The solution you mention
will help to fix the Boost.Threads interfaces that operate on xtime, but it
doesn't really address any other use cases that have the same "jitter"
problem.  Is this a significant issue?  If so, is there a solution?  Maybe
just documentation?

Bill Kempf