busy waiting

There are two ways to wait for something. One is to keep checking, again and again, as fast as you can: 'Is it ready yet? Is it ready yet? Is it ready yet?' The other is to go to sleep and ask to be woken when it is ready. Busy waiting is the first kind. A thread that cannot proceed sits in a tight loop, repeatedly testing a condition, consuming CPU the whole time even though it is accomplishing nothing. It is like standing at the microwave jabbing the door button over and over instead of walking away until the beep.

Concretely, busy waiting looks like while (locked) { /* do nothing, check again */ }. The thread never gives up the CPU; it just spins on the test. The upside is responsiveness and low overhead per attempt: the instant the condition flips, the spinning thread notices immediately, with no cost of going to sleep and being woken (a sleep/wakeup involves a context switch into the kernel and back, which can take far longer than the spin itself). So if the thing you are waiting for will become true in a few hundred nanoseconds — for instance, a lock held only briefly by another core that is actively running — spinning can be the fastest choice.

The downside is waste, and it can be severe. While a thread busy-waits, it occupies a CPU core doing literally nothing useful, denying that core to threads that could make progress. Worse, on a single-core machine busy waiting can be catastrophic: the spinning thread hogs the only CPU, so the thread it is waiting for never even gets to run to release the lock — a self-inflicted deadlock-like stall. The rule of thumb: busy-wait only when the expected wait is shorter than the cost of sleeping and only when the holder is likely running on another core; otherwise use a blocking (sleeping) wait. Real systems often combine the two: spin briefly, and if that fails, fall back to sleeping.