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
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
The solution, if any, is documentation. I have to think a bit more about
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk