Johan Nilsson wrote:

Out of curiosity, who actually prefers using clock times for thread::sleep()? IIRC the implementation still converts the UTC time into a relative time before entering sleep, so it's only misleading to have an absolute time as parameter to sleep.

You would need to ask the pthreads folks. ;-) This behaviour is inherited from there. Roland

Sascha Seewald wrote:

What about adding a function boost::sleep_until() that takes a point in time and change boost::sleep() to take a duration?

I believe the choice was done deliberately, and is more generic. Altough you might not see much use for it, it will allow creating predictable behavior. In the case where you have more complicated timeout scheme only having relative sleep could be a problem. Lets take an example: You have to maintain a task that is started every 10 seconds. Now if you are doing this as: while(true) { ... do something ... relative_sleep(10); } you can see easily that you will accumulate an error from each run of the loop. boost::xtime xt; boost::xtime_get(xt); xt.sec += 10; while(true) { ... do something ... boost::thread::sleep(xt); xt.sec += 10; } you can see now that this works smoothly (of course ... do something ... will be assumed to last < 10 sec) You can always easily write a little relative sleep if you need along the lines: void sleep(int sec) { boost::xtime xt; boost::xtime_get(xt); xt.sec += sec; boost::thread::sleep(xt); } Please don't forget: the threading library supply you with the essential primitives. You might always need to create other convenience functions if needed. You cannot get the behaviour from the example when only a relative sleep is available. Does this make sense to you? Roland

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

Roland Schwarz wrote: [snip]

while(true) { ... do something ... relative_sleep(10);

}

you can see easily that you will accumulate an error from each run of the loop.

boost::xtime xt; boost::xtime_get(xt); xt.sec += 10; while(true) { ... do something ... boost::thread::sleep(xt); xt.sec += 10; }

you can see now that this works smoothly (of course ... do something ... will be assumed to last < 10 sec)

Perhaps, but this method is susceptible to race conditions. System time can (naturally) get changed by e.g. ntpd or Windows Time at any point - including between xt.sec += 10 and thread::sleep() above, as well as during the actual sleep.

You can always easily write a little relative sleep if you need along the lines:

void sleep(int sec) { boost::xtime xt; boost::xtime_get(xt); xt.sec += sec; boost::thread::sleep(xt); }

And if you like to sleep for less than 1 sec, you'll also need to manipulate the nsec member. Not really hard to fix, but another potential source for bugs. Overloading sleep to allow using date_time's posix_time and time_duration as well as xtime would be an alternative.

Please don't forget: the threading library supply you with the essential primitives. You might always need to create other convenience functions if needed. You cannot get the behaviour from the example when only a relative sleep is available.

That is true, but allowing a time_duration or being able to call e.g. thread::sleep(xt, TIME_RELATIVE) would certainly make things easier. / Johan

Roland Schwarz wrote:

Please don't forget: the threading library supply you with the essential primitives. You might always need to create other convenience functions if needed. You cannot get the behaviour from the example when only a relative sleep is available.

This isn't quite true for this specific case. It isn't entirely correct to say that absolute waits are a basic primitive, while relative waits are a convenience. Both are basic primitives; sometimes an absolute timeout better fits the problem, and sometimes the opposite is true. In addition, sometimes the underlying implementation emulates absolute timeouts on top of relative timeouts, sometimes the opposite is true. You can emulate the behavior from the example with relative timeouts as long as you have access to the current time of the clock by which the absolute time is measured. Preemptions aren't an issue specific to relative timeouts since a wait with an absolute timeout can as easily be preempted on the way out as a relative wait on the way in. It's clear that our current xtime mechanism is only a stop-gap measure; unfortunately, nobody has proposed a well thought-out alternative (so far). The C++ committee will have to address the issue one way or the other, though, and there isn't much time left. There is some rationale for POSIX's decision to go with the absolute timeout option in http://www.opengroup.org/onlinepubs/009695399/xrat/xsh_chap02.html A previous section also addresses the monotonic clock.

Roland Schwarz wrote:

Peter Dimov wrote:

...

Preemptions aren't an issue specific to relative timeouts since a wait with an absolute timeout can as easily be preempted on the way out as a relative wait on the way in.

Hmm, sure? I mean "as easily"? I think the probability of being preempted short after having got a time slice from the scheduler is smaller than in the average. (Assuming equal thread priorities.) So one could reason that the way out is more "stable" than the way in.

Yes, you are right. It's much less probable.

Ian McCulloch wrote:

.... So a relative sleep is certainly implementable.

Of course, that is the easy part. ;-) It is more challenging to provide a sleep that indeed will wait for absolute time. That function, as you can see from my other post has some advantages which are missing from relative sleep. And the library provided primitives should be the most generic ones. Roland