Busy Waiting

repeatedly checks a condition in a loop while waiting for access to a critical section (a shared resource). In mutual exclusion, busy waiting happens in the entry protocol as a delay mechanism to control when a thread can progress into the critical section. During busy waiting, the thread remains active, consuming CPU time as it continuously loops, checking for a signal or condition that will allow it to proceed.

In the bathroom analogy used in mutual exclusion, busy waiting would be similar to someone standing at the bathroom door, repeatedly checking if it’s free rather than stepping away and waiting for a notification. This method is inefficient as it consumes resources (CPU time) without making any progress. It contrasts with other synchronization methods where the thread might be put to sleep and only awakened when it is actually able to enter the critical section, saving CPU resources.

Key issue

It can lead to two problematic situations: indefinite postponement (livelock) and starvation. In indefinite postponement, threads might keep looping without gaining access, especially if there’s a deadlock where threads “argue” and neither can proceed. In starvation, a thread may loop indefinitely without getting a chance to access the resource because other threads repeatedly gain access before it.

We need to avoid busy waiting. Consumes CPU resources without accomplishing anything.