Re: [Boost-bugs] [Boost C++ Libraries] #11331: boost::this_thread::sleep_for does not sleep for requested time

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #11331: boost::this_thread::sleep_for does not sleep for requested time
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2015-05-23 15:53:47

#11331: boost::this_thread::sleep_for does not sleep for requested time
  Reporter: Scott Minor <scott.minor@…> | Owner: ned14
      Type: Bugs | Status: new
 Milestone: To Be Determined | Component: thread
   Version: Boost 1.58.0 | Severity: Problem
Resolution: | Keywords: sleep_for

Comment (by ned14):

 Replying to [comment:1 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 [ticket:11331 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.


Ticket URL: <>
Boost C++ Libraries <>
Boost provides free peer-reviewed portable C++ source libraries.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:18 UTC