Std::This_Thread::Sleep_For() and Gcc

std::this_thread::sleep_for() and GCC

Confirmed that it doesn't work here as well. (Recent GCC 4.6 snapshot).

You could do the obvious and simply define it before you include any std:: headers. A bit dirty but will work until GCC fixes it (unless this is intended behavior). The #define shouldn't break anything anyways. Either in source or -D_GLIBCXX_USE_NANOSLEEP flag to GCC.

You might want to try using -std=gnu++0x rather than -std=c++0x, since gnu++0x often pulls in stuff like this.

std::this_thread::sleep_for doesn't exist - Windows 10 g++

I went back to replit.com to see what they were doing to compile the program. Apparently they used the -pthreads switch:

g++ -pthread -std=c++17 -o main main.cpp

Which now works for me.

Why doesn't this_thread::sleep_for need to be linked against pthread?

Why doesn't this_thread::sleep_for need to be linked against pthread?

Because the call to std::this_thread::sleep_for translates into underlying call to nanosleep, which is defined in libc.so.6, and not in libpthread.so.0.

Note that when linking with GLIBC-2.34 and later, using other functions (which previously required -pthread) no longer require it, because GLIBC got rid of libpthread.

See also this answer.

std::this_thread::sleep_for() and nanoseconds

What could explain these numbers?

There's a pretty obvious pattern, all your results are consistently 54000ns greater than the time you request to sleep. If you look at how GCC's this_thread::sleep_for() is implemented on GNU/Linux you'll see it just uses nanospleep and as Cubbi's comment says, calling that function can take around 50000ns. I would guess some of that cost is making a system call, so switching from user-space to the kernel and back.

Why does sleeping for a negative amount of time return 200+ ns, while sleeping for 0+ nanoseconds results in 50,000+ nanoseconds?

At a guess I'd say that the C library checks for the negative number and doesn't make a system call.

Is negative numbers as a sleep time a documented/supported feature, or did I accidentally stumble across some strange bug I cannot rely upon?

The standard doesn't forbid passing negative arguments, so it is allowed, and the function should return "immediately" because the time specified by the relative timeout has already passed. You can't rely on negative arguments returning faster than non-negative arguments though, that's an artefact of your specific implementation.

Is there a better C++ sleep call which would give me more consistent/predictable sleep times?

I don't think so - if I knew of one then we'd be using it in GCC to implement this_thread::sleep_for().

Edit: In more recent versions of GCC's libstdc++ I added:

if (__rtime <= __rtime.zero())
  return;

so there will be no system call when a zero or negative duration is requested.

How to let this_thread::sleep_for(a while)?

Fixed the issue described here: std::this_thread::sleep_for() and GCC

with a #define _GLIBCXX_USE_NANOSLEEP 1 at the beginning of the file.

std::this_thread::sleep_for sleeps for too long

In short, the problem is that you use std::this_thread::sleep_for at all. Or, any kind of "sleep" for that matter. Sleeping to limit the frame rate is just utterly wrong.

The purpose of sleep functionality is, well... I don't know to be honest. There are very few good uses for it at all, and in practically every situation, a different mechanism is better.

What std::this_thread::sleep_for does (give or take a few lines of sanity tests and error checking) is, it calls the Win32 Sleep function (or, on a different OS, a different, similar function such as nanosleep).

Now, what does Sleep do? It makes a note somewhere in the operating system's little red book that your thread needs to be made ready again at some future time, and then renders your thread not-ready. Being not-ready means simply that your thread is not on the list of candidates to be scheduled for getting CPU time.

Sometimes, eventually, a hardware timer will fire an interrupt. That can be a periodic timer (pre Windows 8) with an embarrassingly bad default resolution, or programmable one-shot interrupt, whatever. You can even adjust that timer's resolution, but doing so is a global thing which greatly increases the number of context switches. Plus, it doesn't solve the actual problem. When the OS handles the interrupt, it looks in its book to see which threads need to be made ready, and it does that.

That, however, is not the same as running your thread. It is merely a candidate for being run again (maybe, some time).

So, there's timer granularity, inaccuracy in your measurement, plus scheduling... which altogether is very, very unsuitable for short, periodic intervals. Also, different Windows versions are known to round differently to the scheduler's granularity.

Solution: Do not sleep. Enable vertical sync, or leave it to the user to enable it.

---

Related Topics