Re: [boost] xtime and GetSystemTimeAsFileTime

From: Pete Becker (petebecker_at_[hidden])
Date: 2002-07-01 10:21:05

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.

>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.

        -- Pete

Dinkumware, Ltd.
"Genuine Software"