Re: [boost] xtime and GetSystemTimeAsFileTime

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-07-01 10:36:33

----- Original Message -----
From: "Pete Becker" <petebecker_at_[hidden]>

> At 09:31 AM 7/1/2002 -0500, William E. Kempf wrote:
> >Ahh... an interesting artifact I hadn't considered.  A very corner case
> >kinda problem, but one that should be addressed.
>
> I may not have been clear: this isn't a corner case, but a general failure
> of the code (both the Boost and the Dinkumware implemenations;
fortunately,
> ours isn't shipping yet). The problem is that thread::sleep is supposed to
> sleep until the specified time. As implemented, about half the time it
will
> return early. The example I gave may be misleading, because it used a
sleep
> time of 1 ms. That's the test case that detected it, but the problem isn't
> because of the short duration. It's because Sleep's granularity is smaller
> than xtime's. Assuming an xtime clock tick of 10 ms, the same behavior
will
> occur with any requested time of the form 10*n + 1: nine times out of ten,
> thread::sleep will return early; for times of the form 10*n + 2: eight
> times out of ten; etc. It's worse when the granularity is 55 ms; times of
> the form 55*n + 1 will return early 54 times out of 55. As times get
longer
> the relative error becomes smaller, but if the documentation says that it
> "blocks until xt is reached" then that's what it should do.

Sorry, you're correct.  The contract is broken since we return sooner then
requested.  The timer resolution should only allow for returning later then
requested, not sooner.

> >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?
>
> It's not a problem with xtime per se. It's a generic problem that arises
> whenever you mix data with different precisions. You can't use a calendar
> to time something that's supposed to last seven days, six hours, three
> minutes, and seventeen seconds; the closest you can come is seven days.
You
> can't use GetSystemTimeAsFileTime to time something that's supposed to be
> more precise than that function's tick time (whether it's 10 ms or 55 ms).
> You can't use struct tm to distinguish times that differ by less than one
> second.
>
> The solution, if any, is documentation. I have to think a bit more about
> it, though.

OK, I'll document this and apply the fixes.

Thanks,
Bill Kempf