sleep(1) takes longer each time it is called?

When I call sleep() and check gettimeofday before and after, it sleeps longer each time I call it. Does anyone know of a way to sleep for a set amount of real time?

There is no way, unless you have a real-time OS.

This is OS dependent. On Linux, you can use nanosleep() to get the job done. It has a bit more guarantees that sleep().

You can never get your OS to sleep for exact n seconds unless you have a real-time OS. You can come close, though.
A scheme is to time how long your sleeps take and adjust the following sleeps in order to achieve "semi-accurate" sleep for n seconds. It's the best you can do.

I also tried nanosleep with similar increases every time its called:

Code:

---


struct timespec in, out;
in.tv_sec = 0;
in.tv_nsec = 1;

nanosleep(&in, &out);

---

I was hoping this would sleep somewhere near 1 nanosecond and the first time it is only a few hundred nanoseconds but then the second time its up to hundreds of microseconds...

According to this theory, then after a sufficient number of calls it will be sleeping for hours when you ask for 1 nanosecond. I simply don't believe that. How many measurements did you take? I think you're seeing a random trend that means nothing.

Take ten thousand measurements and see if the trend continues. If it does, something is really whacked with your system.

I don't think you'll ever get it to sleep for 1 nano-second (unless you've got some kind of liquid-nitrogen cooled supercomputer). Most CPU's run at <= 3GHz. Most CPU instructions would take longer than 3 clock ticks, and you'd need a lot of instructions to do a context switch, execute sleep and then context switch again.

Quote:

---

Originally Posted by cpjust

I don't think you'll ever get it to sleep for 1 nano-second (unless you've got some kind of liquid-nitrogen cooled supercomputer). Most CPU's run at <= 3GHz. Most CPU instructions would take longer than 3 clock ticks, and you'd need a lot of instructions to do a context switch, execute sleep and then context switch again.

---

I think his concern is that it seems to take longer each time he calls it... which is almost certainly an illusion.

I wrote a piece of code that pauses execution for a given amount of seconds. It's at my home computer, I will post it later.

Quote:

---

Originally Posted by Babkockdood

I wrote a piece of code that pauses execution for a given amount of seconds. It's at my home computer, I will post it later.

---

And that will probably also appear to sleep for longer each time it is called, quite simply because his timing code is probably wrong.

lsad, show how you are timing these.

Code:

---

#include <time.h>

wait(float x)
{
        time_t start;
        time_t current;
        time(&start);
        do
                time(&current);
        while(difftime(current,start) < x);
}

---

This always works for me.

Quote:

---

Originally Posted by Babkockdood

Code:

---

#include <time.h>

wait(float x)
{
        time_t start;
        time_t current;
        time(&start);
        do
                time(&current);
        while(difftime(current,start) < x);
}

---

This always works for me.

---

It's also greedy and naive.

It may surprise you how sleep(N) works. It doesn't try to sleep for N amount of time, instead it sleeps for AT LEAST N amount of time, and then returns.

Which means that, with a busy multi-tasking computer, you could have a good deal more sleep time, than you requested, AND in any case, you will ALWAYS lose a tiny amount of time. Even on a computer running no other (non OS) applications.

If you put your sleep() calls, into a loop, you should see some increase in lost time, simply because you have added to the work load of the OS. If the load lightens, the sleep times will get trimmed back down.

Quote:

---

Originally Posted by Babkockdood

Code:

---

#include <time.h>

wait(float x)
{
        time_t start;
        time_t current;
        time(&start);
        do
                time(&current);
        while(difftime(current,start) < x);
}

---

This always works for me.

---

That is a busy loop, not a sleep. CPU usage will be maxed out by executing that code. Using such code for a delay of a second is downright cruel!
That technique is only meant for spin-locks where the duration is expected to be typically perhaps less than tenths of a millisecond.