[Boost-users] boost/thread/xtime.hpp

From: Weston Markham (WMarkham_at_[hidden])
Date: 2004-12-14 10:46:58

The Boost.Threads library provides boost::xtime and boost::xtime_get.  I
have some questions and concerns about these:

I read the page at http://www.cl.cam.ac.uk/~mgk25/time/c/ in order to
understand what the intended semantics of boost::TIME_UTC are.  I assume
that this matches the possible C proposal that is referred to in the Boost
documentation.  I also read the "Terminology" section of the Boost.Date_Time
documentation.

1.  First of all, should these (boost::xtime and boost::xtime_get) be
treated as deprecated, in favor of the types and functions in
Boost.Date_Time?  (If so, then my further questions might be merely
academic.)

2.  It appears that the boost::xtime type is used both for the purpose of
measuring the length of an interval of time, as well as for designating
individual points in time.  Is this correct?

3.  thread::sleep (as well as other Boost.Thread functions) delays the
execution of a thread for a specified interval, which implicitly begins at
(approximately) the time of the call.  Is its input parameter intended to be
the other endpoint of the interval, or is it intended to measure the length
of the interval?  Both the documentation and the implementation lead me to
believe that the former is the case.  However, the documentation seems to me
to be slightly ambiguous, and, of course, using a function's implementation
to determine its expected behavior is questionable.  (A similar question
applies to the TimedLock concept, although I haven't looked at its details.)

4.  The only type of clock that xtime_get supports (according to the
documentation) is TIME_UTC.  This does not seem useful to me, because I am
mainly interested in providing accuracy for the intervals being timed, as
opposed to providing accuracy relative to some externally-defined epoch.

5.  Does boost::thread::sleep use the boost::TIME_UTC clock?  If the
parameter specifies the other endpoint, then I don't see how anything else
could make sense.

6.  What happens when someone applies a correction to the system time on my
machine, in an attempt to synchronize it with UTC?  Intuitively, I expect
any functions that report UTC time to report a discontinuity, because the
newer estimate should always be considered more accurate, but it was not
known until the adjustment was made.

Consider the code that I currently write in order to "sleep 5 seconds":

boost::xtime xt;
boost::xtime_get(&xt, boost::TIME_UTC);
xt.sec += 5;
boost::thread::sleep(xt);

How long should the waited interval last?  In most cases, it will be just
under 5 seconds.  If a leap second occurs within 5 seconds after the
xtime_get, the wait ought to last about 6 seconds.  (My guess is that most
implementations would not provide this behavior, however.)  And in the event
that the TIME_UTC clock does not exactly match UTC time, and is subject to
adjustments, the sleep could be instantaneous, or perhaps last a minute or
more.  (Here in my office, my workstation and the phone system disagree by 1
minute right now.)

If boost::thread::sleep is intended to wait until a specified UTC time,
(this is the conclusion that I have drawn from the documentation and the
current implementation) then I think this is a conceptual flaw in the
library.  I have never had any need to do such a thing.  It is always more
important to me in this context that the duration of the interval be
accurate, rather than its relation to, say, the rotation of the earth.
Admittedly, I will get the behavior that I want in most cases.  However, it
seems senseless to me to confuse the matter of timing short intervals with
reasonable accuracy by introducing UTC time, particularly when practically
all computing hardware already has the facilities to perform the measurement
task at hand, but does not necessarily have any means of discovering the
current UTC time.

My concerns could be mitigated if boost::TIME_UTC were renamed so that it
did not have UTC in its name.  It should then be documented as indicating a
request for a (monotonic, if possible) clock that is suitable for timing
intervals with a resolution around 1 second.  The underlying implementations
should then prefer system calls that enable accurate measurement of
intervals, rather than synchronization with an external time base.  Plus,
the documentation for boost::thread::sleep should make explicit the manner
in which it will interpret its argument.

A search of the Boost developers' list on Gmane reveals a "problems with
boost::thread" thread that appears to mention the issue of applying
adjustments to the clock used for TIME_UTC.  (And appears to have good
suggestions for adding types to fix the ambiguity that causes questions #2
and #3.)  I only found it after typing up the bulk of this message.
However, it would be good to know if the future direction of the library is
to incorporate the suggestions there.

Weston