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.