From: Ulrich Eckhardt (doomster_at_[hidden])
Date: 2006-04-12 01:59:24
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk