From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-07-11 12:25:00
Howard Hinnant wrote:
> Speaking of which, I've never been happy with "t" in the
> ScopedTimedLock docs. I've always felt it was ambiguous. Does t
> represent an absolute time, or a change in time? Both interpretations
> are useful.
It represents an absolute time. The main rationale for using absolute times
is condition::timed_wait, which needs to be called in a loop. A relative
time would need to be recalculated for each iteration. But relative times
are useful, too.
> In the Metrowerks::threads lib I have:
> scoped_timed_lock(mutex_type& m, const universal_time& unv_time);
> scoped_timed_lock(mutex_type& m, const elapsed_time& elps_time);
> Where universal_time and elapsed_time are simplistic structs (like the
> boost time), but represent absolute and delta times respectively. They
> can also be added and subtracted as makes sense (e.g. you can add a
> universal_time and an elapsed_time, or two elapsed_time's, but you
> can't add two universal_time's). I took the Posix route and defined
> universal_time as the number of seconds and nanoseconds since midnight
> Jan. 1, 1970, UTC. The universal_time default constructor returns the
> current time.
One problem with the UTC time is that it can jump backwards, if the system
time changes. Maybe we should consider using (or adding) a monotonic time.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk