10

Note, this is not a question about std::condition_variable::wait_for(). I know that can wake spuriously.

My program’s behavior suggests the answer to this question is Yes, but the STL documentation is quite clear for the condition_variable case. At least at cppreference.com, the correct answer for this_thread appears to be No.

Compiler is gcc 4.8.1, in case this is a defect.

sbabbi
  • 11,070
  • 2
  • 29
  • 57
Andrew Lazarus
  • 18,205
  • 3
  • 35
  • 53
  • 2
    How do you measure the time? – sbabbi May 29 '15 at 20:38
  • `std::chrono::seconds(50)` I was running a unit test with many timestamped messages and there was no corresponding gap. Indeed, this caused the test to fail. – Andrew Lazarus May 29 '15 at 20:41
  • I can't find any mention of spurious wakeups for `std::this_thread::sleep_for()` in the `C++11` standard. Only for `std::condition_variable`. – Galik May 29 '15 at 20:50
  • 1
    Did you link the thread library in? – Yakk - Adam Nevraumont May 29 '15 at 21:00
  • Well `sleep_for` is implemented on top of `usleep`/`sleep`. I assume that a bug there is unlikely. – sbabbi May 29 '15 at 21:06
  • 2
    I am unable to reproduce, do you have an example code that fails? – Galik May 29 '15 at 21:12
  • Just a thought, are you using the `std::chrono::steady_clock`? The `C++11` standard says you *should* use a steady clock. – Galik May 29 '15 at 21:22
  • @Galik No, it says the *implementation* should use a steady clock. A `duration` has no clock associated with it. – T.C. May 29 '15 at 21:25
  • @Galik Sometimes it's fine, but the code would not be very interesting. `LOG("stuff"); std::this_thread::sleep_for(std::chrono::seconds(50); LOG("More stuff")` where LOG is a macro that includes a timestamp in the output. I was at the terminal when this ran, and I could just tell without looking there was no 50 second sleep. – Andrew Lazarus May 29 '15 at 22:30
  • 1
    DID YOU LINK THE THREAD LIBRARY IN? (What are your compiler command line options, all of them please) – Yakk - Adam Nevraumont May 30 '15 at 12:28
  • You are not using `std::clock` to compute the timestamps, aren't you? – sbabbi Jun 01 '15 at 19:46
  • 2
    Able to reproduce on GCC 4.8.5. There is also a bug reported (and confirmed) against GCC 5.1.0 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66803) – Paolo Brandoli Feb 28 '18 at 08:44

2 Answers2

9

The relevant sections of the C++ Standard (paragraphs [thread.thread.this]/7-9) do not mention anything about spurious wake-ups for std::this_thread::sleep_for, unlike e.g. for std::condition_variable::wait_for.

template <class Rep, class Period>
void sleep_for(const chrono::duration<Rep, Period>& rel_time);

7 Effects: Blocks the calling thread for the relative timeout (30.2.4) specified by rel_time.

8 Synchronization: None.

9 Throws: Timeout-related exceptions (30.2.4).

This implies that the behavior you are observing is non-conforming.

Andy Prowl
  • 124,023
  • 23
  • 387
  • 451
4

Able to reproduce on GCC 4.8.5.

There is also a bug reported (and confirmed) against GCC 5.1.0 (gcc.gnu.org/bugzilla/show_bug.cgi?id=66803)

Paolo Brandoli
  • 4,681
  • 26
  • 38