2

Can it be a loop with or without statements?

while (1)
{
   //Empty
}

OR

int i = 0;

while (1)
{
   i++;
}
user13364
  • 21
  • 1
  • 1
  • 2
  • 4
    As both of your examples would suck up close to 100% of the CPU, I'd call them EXTREMELY busy loops. The minimal loop would include a sleep or other task. – T.Rob Feb 06 '11 at 03:46
  • How to prevent it from being optimized away: https://stackoverflow.com/questions/7083482/how-to-prevent-gcc-from-optimizing-out-a-busy-wait-loop – Ciro Santilli新疆棉花TRUMP BAN BAD Nov 08 '19 at 09:46
  • Both examples yield to UB, as-is. signed overflow for second, and both with [Is empty loop UB](https://stackoverflow.com/questions/3592557/optimizing-away-a-while1-in-c0x). – Jarod42 Apr 02 '20 at 11:28

3 Answers3

13

A "busy loop" or more commonly "busy wait" is an active polling where the application is waiting on some event to occur and continuously checks for it. Typically this includes a timed sleep or other task which gives up CPU time so that another process can provide the expected input.

Contrast this with a callback. While waiting on a callback, the program consumes no CPU cycles. Typically the program will "register" a callback routine which some monitoring application invokes based on some event.

The distinction is that the program in a busy-loop consumes CPU and time slices while waiting while the callback mechanism allows a program to consume no (or almost no) CPU while waiting.

T.Rob
  • 30,636
  • 9
  • 56
  • 101
  • 2
    But wouldn't the program implementing the callback mechanism still need to run a busy loop in order to know when to hit the callback? How is this more efficient? – CMCDragonkai Nov 11 '13 at 22:27
  • An example is the difference between pub/sub using HTTP versus MQTT. An HTTP-based client needs to poll the HTTP server and if it needs to be responsive will do so every second or so. An MQTT client establishes a socket and listens on it. The MQTT server sends data when and if ready. The difference if the client happens to be on a cell phone is massive in terms of CPU utilization, bandwidth utilization and battery life. The HTTP version implements a busy loop, the MQTT version implements a blocking TCP call or a callback where the thread with the socket remains in waiting state. – T.Rob Nov 12 '13 at 03:01
  • 1
    I understand what you're saying in the abstract. I'm just confused of how such is implemented in the concrete going down all the way to the hardware. Something must still be polling because fundamentally for something to react to something else, it must check if that something else has happened right? – CMCDragonkai Nov 12 '13 at 06:23
  • Sure. The question is whether it is contained in the code of the app or relegated to something else like the OS or to hardware. If the app does a blocking call then he OS wakes it up. If the app registers an interrupt at the hardware level, then the CPU branches to that code when the interrupt pin goes high. In either case the logic of what happens while the app waits is not contained in the app. – T.Rob Nov 12 '13 at 14:09
4

To me, a busy loop is a loop that never blocks.

Blocking is a behavior provided by the operating system that allows a thread to consume NO cpu cycles until some condition is met (a condition variable is signaled, or perhaps just data arriving on a socket (as recv() will block)).

In a traditional Win32 main loop, you potentially block every time your thread calls GetMessage(). All event driven windowing system are similar in this way.

dicroce
  • 41,038
  • 26
  • 94
  • 136
3

I'm pretty sure you're talking about busy wait where you have a loop polling for some condition every iteration.

Nathan Pitman
  • 3,320
  • 17
  • 19