Using a for-loop instead of sleeping? [on hold]

Back in the day, home computers used to have a “turbo” button, which (when activated), made the processor slower. The problem was that games were coded around an input loop that was expected to take a specific number of milliseconds. If the loop was executed faster, the whole game would speed up, becoming unplayable.

Today, computers have vastly different speeds and performance characteristics, so NOPping isn't reliable in any way (will it take half a second? half a year?). Furthermore, compilers are generally free to remove code that doesn't do anything – compiling your snippet under -O3 would hopefully remove that loop.

Don't use an ugly kludge just to achieve better compilation speed. Do it right – consider yourself a code craftsman, not a code monkey (no offense, rolfl).

This is called 'busywaiting' or 'spinning', and will work but has the following disadvantages:

1. It will perform 'work' on your program instead of yielding control to OS and other programs - so it doesn't "play nice" with others; on a common computer there are many programs running at the same time that could also like to use that CPU instead.

2. Busywaiting creates unneeded load on CPU, preventing it from idling - this results in extra heat, fan noise and lower battery life on laptop computers or mobile devices.

3. The delay is unpredictable - it will vary greatly depending on the computer and also the compiler, which may "optimize it away" to no delay at all, as other answers noted.

In short - it will function, so if it's a one-off script for your own use then it can be okay, but if it's code meant for production use or something that will need to be maintained in the future, then don't do it this way.

This technic is called Spinlock or busy waiting. It is implemented for example in Oracle database software to coordinate access to memory structures between different processes (latches).

It seems to be useful if the overhead of sleeping which results from context switching is larger than waste of CPU time when spinning. This is the case if the expected wait time is very short. Very short means some clock cycles and is far less than 2000 ms that you use in your example.

The compiler will not optimize the loop away if it is implemented correctly. This C example using a volatile variable is from busy waiting .

...
volatile int i=0;
...
while (i==0);
...

volatile tells the compiler that the value of the variable i can be changed from outside the current thread and so the compiler does not throw away the while-loop.

Busy waiting is listed as antipattern here. So you should not use it if you are not completely aware of its consequences.

Trying to avoid the inclusion of unistd.h seems not to be a valid reason to use busy waiting.

The other answers here address the specific issues with your loop, and hopefully have convinced you that it is not the right approach. I want to comment on your motivations.

Why do you want to avoid unistd.h? It is entirely reasonable to include a header for just one function, and in the vast majority of cases there is no compelling reason not to.

If you are concerned about portability, just do something like this:

#if defined(__linux__)
#  include <unistd.h>
#elif defined(_WIN32)
#  include <windows.h>
#  define sleep(s) Sleep((s)*1000)
#endif

Then use sleep(seconds) everywhere.

Two big reasons why that's a bad idea:

1. The time spent on a given loop is very dependent on the computer running it. Ever played Quake on a modern computer? The frame rates are through the roof, and I hope that's not a surprise. More powerful computers can perform more calculations in a set time. If your computer takes 10 seconds to complete a loop, a more powerful computer might finish in 5 or less, and an older computer might take significantly longer.

   So, couldn't I just do this?

   #include <Mmsystem.h> //timeGetTime
   void Stall(unsigned long ms)
   {
       unsigned long start = timeGetTime();
       unsigned long passed = 0;
       while (passed < ms)
       passed = timeGetTime() - start;
   }
   

   Yeah, that would ensure that the same time is taken to finish the function. But don't get too excited; I said two big reasons.

2. Sleep functions set your thread in a sort of "do not disturb" state, allowing your operating system to perform other tasks (handling other threads, cleaning up your thread) while your thread daydreams. While a human could look at the line and interpret it as "do nothing", your computer is wasting power blowing through that empty loop as fast as it can.

   So, I can do this?

   #include <Mmsystem.h> //timeGetTime
   #include <WinBase.h> //Sleep
   void Stall(unsigned long ms)
   {
       unsigned long start = timeGetTime();
       unsigned long passed = 0;
       while (passed < ms)
       {
           passed = timeGetTime() - start;
           Sleep(0);
       }
   }
   

   Better, but it still wastes CPU resources when it doesn't have to. And if there are no other threads running, Sleep(0) immediately returns to your thread, meaning your CPU is still running at maximum speed.

Conclusion: for most applications, stick with sleep functions.

The biggest single issue with this approach, other than eating processor cycles, is that the for loop will be removed by the optimiser if you enable any level of optimisation in the compiler. Suddenly you find that code that ran just fine in debug mode, stops working.