Boost C++ Libraries: Ticket #11331: boost::this_thread::sleep_for does not sleep for requested time

owner changed

viboes — Fri, 22 May 2015 22:25:55 GMT

owner changed from Anthony Williams to Niall Douglas

Niall, I believe that you did this changes. Could you recall us why this was necessary?

Niall Douglas — Sat, 23 May 2015 15:53:47 GMT

Replying to viboes:

Niall, I believe that you did this changes. Could you recall us why this was necessary?

Yep, this change was all me.

The change was not my design however. boost-dev was asked for options, and this design was the consensus that emerged. I personally didn't agree with it, but there you go. I might add that just because we say that we don't mind a +/- 1 sec tolerance doesn't mean that Windows actually gives us that, it just /may/ give us up to that.

A clamp on the upper bound of the tolerance was considered unnecessary precisely because the correct wakeup is specified to Windows, and whatever the next interrupt is will execute the timer. The tolerance is not automatic lateness, it's simply permission to increase variance past the system tick rate of ~30ms. That has huge benefits for battery operated devices, and it also helps catch buggy code like the OPs.

Regarding this statement:

Replying to Scott Minor <scott.minor@…>:

However, we are dependent on sleep_for() being as accurate as possible; for us, this is a breaking change.

No, it is your algorithm which is broken. If your use depends on any accuracy at all from any STL11 timed wait implementation, your code is wrong and needs to be fixed. The C++ standard is very clear than you can expect no guarantees whatsoever in any timed sleep function (including any amount of actual sleep), and any code which is written to require accuracy is incorrect. I might add that the Microsoft STL may be likely to gain a similar timer design to Boost.Thread soon as I coordinated with Stephan what I was about to change in Boost.Thread. We're just earlier to ship, that's all.

Now, that said, I personally speaking would just love if we could add timer hardness/softness support to the STL and very considerably strengthen those guarantees on platforms allowing it, but that's probably work best done in Boost.Thread v5 (and the associated changes in Boost.Chrono) as an early design imperative so the rewrite is timer hardness/softness friendly from the very beginning.

Niall

scott.minor.13@… — Sun, 24 May 2015 04:48:17 GMT

Thanks for the follow-up. How would you recommend users of Boost 1.58 rewrite their algorithms if they are impacted by this behavior?

Niall Douglas — Sun, 24 May 2015 21:33:27 GMT

Replying to scott.minor.13@…:

Thanks for the follow-up. How would you recommend users of Boost 1.58 rewrite their algorithms if they are impacted by this behavior?

Depends on the algorithm. 95% of the time if you need to wait for exactly 30 seconds down to the millisecond, there is something very wrong with your assumptions because that is only ever somewhat likely on a non-realtime OS, or any system able to swap memory onto disc.

For example, if you actually merely need to poll something every thirty seconds, what you do is to adjust subsequent timeouts for when some timeout is late, and you aim for 120 wakeups per hour, not a sleep of 30 seconds each. You obviously need to adjust readings according to wakeup error. This is the kind of thing engineers ought to do from the beginning, but it's just hugely easier not to.

Another strategy is you sleep 80% of 30 seconds, then enter a yield loop for another 10%, then a spin loop for the remaining 10% - this delivers microsecond accurate sleeps most of the time. For any occasions where the OS context switches at exactly the wrong moment you still need a method of detecting the error and throwing away/retrying the exact wait.

Niall

viboes — Fri, 29 May 2015 18:07:41 GMT

Could we close the issue as works as expected?

viboes — Mon, 01 Jun 2015 20:21:37 GMT

Niall, why do the boost dev list wanted the change? Have you a pointer, please? What issue was this change fixing?

Niall Douglas — Mon, 01 Jun 2015 23:42:41 GMT

Replying to viboes:

Niall, why do the boost dev list wanted the change? Have you a pointer, please? What issue was this change fixing?

I believe the discussion began with #9856 which contains links to the appropriate boost-dev threads.

Niall

status changed; resolution set

viboes — Sun, 28 Jun 2015 09:39:04 GMT

status new → closed
resolution → wontfix