1

gcc seems to have a problem with sleep_for and sleep_until functions (of namespace std::this_thread). I do some simple example with future and conditional variables. gcc actually uses the System Clock instead of Monotonic Clock and this can cause jumps over time. In my example in some case the clock jumps afterward and my timeout expires immediately.

The Bug should be this GCC Bug 41861

I see that in the future gcc 10 release the bug maybe is resolved, but until the realease of the new version of gcc there is a solution for this problem? Someone have noted that?

UPDATE: This Bug is resolved or not yet in the last compiler version ( GCC 10.2 )?

Zig Razor
  • 3,381
  • 2
  • 15
  • 35
  • 2
    _" I don't post the code of my example because are very simple test and i trashed them"_, well that's unfortunate. I'd advise you to rewrite them. – YSC Jan 07 '20 at 13:52
  • Don't use those functions, I suppose? Or tell your users not to change the clock while your program is running? (or don't tell them that until they ask you about it) – user253751 Jan 07 '20 at 13:53
  • 2
    relevant part of the Standard: https://eel.is/c++draft/thread.req.timing#3 _"The functions whose names end in _­for take an argument that specifies a duration. These functions produce relative timeouts. Implementations should use a steady clock to measure time for these functions."_ – YSC Jan 07 '20 at 13:55
  • 1
    I seem to recall this is a known issue that I came across years ago. Will try to come up with some references – Lightness Races in Orbit Jan 07 '20 at 13:56
  • @YSC i read this, but i noticed that the compiler doesn't do what the standard says. – Zig Razor Jan 07 '20 at 13:58
  • @LightnessRacesBY-SA3.0 thank you so much, all amswer are appreciated – Zig Razor Jan 07 '20 at 13:59
  • however the code are the simple example of the c++reference site with some timestamp placed in the right place. – Zig Razor Jan 07 '20 at 14:00
  • I dont post my answer because it was simple and I trashed it. Sorry, couldnt resist :P. Seriously, an example that is very simple is the best example, you should post it – 463035818_is_not_an_ai Jan 07 '20 at 14:08
  • 1
    An example would be interesting (and the question should have included a link to the GCC bug page), but we don't need code to answer the question "how can I work around X known issue in Y software until version Z?" – Lightness Races in Orbit Jan 07 '20 at 14:09
  • @LightnessRacesBY-SA3.0 I correct the text of my question with the bug link thank you so much – Zig Razor Jan 07 '20 at 14:17
  • 1
    It's worth noting that that bug does not contain any code change to fix the problem for `this_thread`. There may be another one which is the one you're actually referring to. Where did you get the information that it was fixed in GCC 10? – Lightness Races in Orbit Jan 07 '20 at 14:29

1 Answers1

3

This is indeed a stunning bug, fixed in GCC 10 (bug 41861 describes it in the context of <condition_variable>).

Back in the day when I encountered this, it was tempting to fall back on Boost to get the proper behaviour, but even that was broken until 1.61. And nowadays it would be strange to mix Boost and standard timing/threading code anyway, since the standard facilities are generally mature and preferred (irony detected!).

What I did at the time was to create a replacement for condition_variable that wrapped POSIX functionality directly.

Whatever you're doing with sleep_for/sleep_until, I suspect you have little recourse but to do the same thing, sorry.

Lightness Races in Orbit
  • 378,754
  • 76
  • 643
  • 1,055