On Tuesday 11 April 2006 03:31, Kim Barrett wrote:
Regrettably, good monotonic clock support seems to be weak at both the standards level and in actual implementations. Since boost.thread is largely a portable wrapper around the underlying OS-specific facilities, that probably makes it rather difficult for boost.thread to do better.
I think there is still way for this to improve though. Firstly, I would change xtime_get() to return either an xtime struct or void, and throw on failure. With that, one could still implement monotonic clocks on systems that support it. What I mean is that I would be better off with a half-way solution than no solution at all.
On a related note, why doesn't the threading lib offer any means to yield for a certain time? In more than nine out of ten cases, this is the way I do things, waiting for a certain point in time - like Boost.Thread does - is rather the exception than the rule.
Because a user can easily synthesize a relative time measuer on top of an interface that uses absolute times, but there is a race condition associated with a user attempting to specify an absolute timeout on top of an interface that uses relative timeouts. See, for example, the Rationale section for pthread_cond_timedwait() in the Single Unix Specification for more details.
I read that spec, and while it is itself consistent it won't help in my situation. It explicitly says that the implementation should handle the case that a user advances(!) the clock, i.e. when the clock skips a few ticks. My case is different though, because I need to handle gracefully when the system clock moves backward, too. In other words, the race condition exist also in the case of absolute times. In case you wonder, this is part of a maintainance reminder system and in order to test that it asks for maintainance when X weeks have elapsed and that it cancels operation when X+Y weeks have elapsed, people simply turn the clock ahead and then finally turn the clock back again. If this happens between getting the current time and waiting for current time plus X, this will effectively produce a wait that goes for several weeks instead of milliseconds. Another part of the system checks for certain conditions and if they persist for more than X milliseconds it performs some actions. This, too, won't work when the clock suddenly skips ahead or backward. All in all, I think I really need monotonic time or at least the best approximation thereof, whether it is supported on all systems or not. Uli