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
Weston Markham wrote:
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.)
Possibly not, because xtime is intended for efficient low-level time representation whereas ptime may be more heavyweight. <snip>
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.
Given an accurate implementation of TIME_UTC, yes; a probably find an accurate implementation of TIME_TAI preferable.
(My guess is that most implementations would not provide this behavior, however.)
Your guess is right. Since leap seconds are scheduled no more than a few months in advance, it is impractical for operating systems to take them into account in time calculations, so they tend to ignore them completely, though some C libraries for Unix can be configured to take them into account (with the result that their file timestamps are shifted relative to those of other Unix systems). NTP implementations commonly compensate for leap seconds by adjusting the system clock to tick slightly slowly for a few minutes. So the system clock which Boost relies on tends to be an approximation to TIME_UTC and not to TIME_TAI.
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.)
Yes, that's the way most systems seem to do things. For this reason, good NTP implementations correct the clock only gradually if it is not too far out to start with.
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.
I quite agree that that's what usually wanted, but I'm afraid that may not be possible to implement. <snip>
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.
So you want TIME_MONOTONIC?
The underlying implementations should then prefer system calls that enable accurate measurement of intervals, rather than synchronization with an external time base.
Actually there is a good reason for using points in time rather than durations, which is that you don't have to recalculate them after being interrupted by something that doesn't affect the timeout.
Plus, the documentation for boost::thread::sleep should make explicit the manner in which it will interpret its argument.
Of course.
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.
The status of Boost.Threads is a bit unclear to me. Ben.
participants (2)
-
Ben Hutchings -
Weston Markham