Re: [boost] [thread] monotonic xtime

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