Re: [Boost-users] [thread] bug: thread::sleep can't 'Idle'

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2006-10-12 10:24:04

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