Is behaviour well-defined when `sleep_until()` specifies a time point in the past?

Question

The C++11 standard talks about what should happen if the system clock is adjusted such that the time point passed to sleep_until() is now in the past - but I can't see anywhere that addresses the case when the specified time point is already in the past.

Have I simply overlooked something, or is it really not specified - even as UB or implementation-defined?

A similar question arises if sleep_for() is invoked with a negative duration.

This is not really a specific coding case or problem you address here. It is rather a discussion — Rockbar, Oct 04 '16 at 09:13
@Rockbar: It's extremely specific, and a perfectly well-formed question. — Lightness Races in Orbit, Oct 04 '16 at 09:15
As I remember, the spec provides different clocks. Some are guaranteed to be strongly monotonically increasing (dont jump back), others are not. — Johannes Schaub - litb, Oct 04 '16 at 09:16
I do not see the concrete coding application it is used, throws error, error log, etc. To me It is more a general question. — Rockbar, Oct 04 '16 at 09:19
Qt4's QThread::sleep function has this bug on linux, where it may sleep "forever" if you adjust time forward. I heard some timed boost lock functions also had problems with this. — Johannes Schaub - litb, Oct 04 '16 at 09:22
@Rockbar: It's not a general question. It's a specific question about a specific behaviour of a specific language, according to a specific language standard. Stack Overflow is actually supposed to be for these awesome questions, not the endless "debug my code for me" nonsense we're spammed with instead! We want _more_ of this, not less!! — Lightness Races in Orbit, Oct 04 '16 at 09:31
I will reference to your statement next time I ask some silly question :-) — Rockbar, Oct 04 '16 at 09:39
@Rockbar don't do that. This is not a silly question. So it won't apply.. — bolov, Oct 04 '16 at 11:30

Alexey Guseynov · Answer 1 · 2016-10-04T09:20:28.073

5

Calculation of time until which to sleep and calling sleep_until() is not atomic. It is possible that you calculate time, then context switch occurs, system is overloaded, swapping, and actual call to sleep_until() happens much later. So if sleep_until() does not wake up when time is in the past, then it is useless, because in such situation you never can be sure that your thread will be waken.

Requirements for the function are specified in section 30.2.4 of the standard. And it specifies that return time should be Ct + Di + Dm where Ct is the time you have specified, Di is a delay induced by overhead oof interrupt, function return and scheduling, and Dm is delay caused by resource contention. In such case Di includes time that passed before you have called sleep_until() and the function returns as soon as it can.

edited Oct 04 '16 at 09:20

answered Oct 04 '16 at 09:11

Alexey Guseynov

5,116
1
19
29

I disagree - Di is described as the "quality of implementation" delay. What we're talking about here is a logical question that would remain even if Di and Dm ("quality of management" delay) were both zero. – Jeremy Oct 04 '16 at 09:27
1

`sleep_until` is required to return at Ct + + . In this case we need a lot of time to schedule it because we want it done yesterday. – Alexey Guseynov Oct 04 '16 at 09:38
1

Yes the fact that any delay could be introduce anywhere in your program means that when you call `std::sleep_until(x)`, x might already be in the past. Even if you do `if (x > SomeClock::now()) std::sleep_until(x);`. In this regard, the only reasonable/reliable implementation is to consider a timeout in the past as (already) reached. – ysdx Oct 04 '16 at 10:17

score 2 · Answer 2 · answered Oct 04 '16 at 09:07

2

You're over-analysing this.

Does the standard explicitly say "if the target time is in the past, there will be no block or wait"? No.

Does it go out of its way to explain how a time step will shrink or obliterate the timeout? Yes. Furthermore, it defines these timeouts in terms of relative timeouts.

The intent, I think is fairly clear. It's one of those situations in which you can but have to deduce it from the English wording: if the timeout is immediately satisfied, nothing is going to happen.

More interesting is that it does not appear to be well-defined as to whether there will be an instantaneous lock-and-unlock cycle, in either case.

answered Oct 04 '16 at 09:07

Lightness Races in Orbit

378,754
76
643
1,055

Even if it was in the future at the time of the call, it may be in the past when control arrives on the implementation by the scheduler. So I'm not sure there isn't an inherent problem to specify behavior for "past" times. – Johannes Schaub - litb Oct 04 '16 at 09:15
@JohannesSchaub-litb: That's an implementation problem – Lightness Races in Orbit Oct 04 '16 at 09:16
On second thought, there may be problems specifying when a passed time is in future, however for monotonic clocks, passing a time that is guaranteed to be in past is possible. – Johannes Schaub - litb Oct 04 '16 at 09:20
"The intent, I think, is fairly clear" - the root of all evil. – Jeremy Oct 04 '16 at 09:23

score 0 · Answer 3 · answered Oct 04 '16 at 09:07

0

From here

Blocks the execution of the current thread until specified sleep_time has been reached.

ie if the time is in the past, then it won't block for very long.

answered Oct 04 '16 at 09:07

UKMonkey

6,941
3
21
30

2

cppreference.com is not an ISO Standard document – Lightness Races in Orbit Oct 04 '16 at 09:08
I will locate a better reference then :P – UKMonkey Oct 04 '16 at 09:08
From here http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3337.pdf "Blocks the calling thread for the absolute timeout" It's pretty clear that if the absolute timeout is in the past, then the blocking will expire pretty fast. – UKMonkey Oct 04 '16 at 09:19
OTOH it could be argued that a negative absolute timeout cannot exist and thus has no formal definition. You might then not be able to rely on an implementation to do a specific, well-defined thing. Personally I think the odds of that are low, but as I say in my answer there is indeed no actual wording for this case. – Lightness Races in Orbit Oct 04 '16 at 09:33
Exactly - there's no wording, meaning that it would be unexpected for it to raise any sort of error, since it has stated in the ISO what the conditions are for an error to be raised. – UKMonkey Oct 04 '16 at 09:35
@UKMonkey: I'm more concerned about it sleeping forever. – Jeremy Oct 04 '16 at 09:55
It's not clear that a past time won't sleep for a long time. – Mike Mestnik Oct 25 '18 at 07:06

Is behaviour well-defined when `sleep_until()` specifies a time point in the past?

3 Answers3

Linked