Ian McCulloch wrote:
The problem is, that in most cases boost::sleep() converts the absolute time into a relative time anyway,
This is an implementation detail (of an admittedly bogus implementation).
and this is a race condition (if the thread is interrupted after retrieving the current time, but before the relative duration is calculated, you end up sleeping too long).
This is the outcome of the implementation. But view it as an approximation to the ideal.
You can convert a relative time into an absolute time safely, but not the other way around.
No, the same reasoning that you have done applies, simply you might sleep too short. I am sort of convinced, that both functions need be available, to be able to express intended meaning. (Implementaion details aside). However a little doubt remains, that it will be possible to implement relative waits at all. Which is the reference point from where on relative time will be measured? Function invocation? Will not be implementable -> preemption between invocation and opsys call. But I have to admit that the same applies to absolute time, since the thread might be preempted between scheduler wake up and time when the boost::sleep will return. Altough it is less likely that we will be preempted anytime too soon after just having got a time sclice from the scheduler. Interface extension possibly as an overload: sleep(long sec, long nsec) which will mean to do a relative sleep, and translates to the operating systems native meaning of sleep. I'll put this into the list of TODO's.
Well, if you really cared about getting an accurate absolute sleep it would be in the context of a condition variable timed wait, in which case sleep() is not the right function anyway. The primitive in this case is some variant of the operating system sleep system call, which AFAIK always takes a relative time.
I am afraid this is true. :-( But having a sleep that will wait for absolute time is a need to have. (Or you will need to emulate it by timed_wait on a condition) Btw.: xtime for long has been recognized as a candidate to be replaced by a better time function anyways. We certainly will need a kind of monotonic time too. Where I do see the real problems is, as you have pointed out, that it will be very hard to convince a operating system scheduler to wake up a thread at absolute time. Roland