Polling vs Interrupt-Driven I/O
Software can wait for an event by repeatedly checking or by being interrupted; each has distinct latency, overhead, and determinism characteristics.
Two Ways to Wait
When software must respond to an external event, it can either poll, repeatedly reading a status until the event appears, or use interrupts, letting the hardware signal the processor when the event occurs. The choice affects latency, processor efficiency, and how predictable the timing is, and the right answer depends on the event's rate and urgency.
Polling
Polling loops read a status flag over and over. Its advantages are simplicity and highly predictable timing: if the loop is tight and dedicated, the response latency is the polling interval, with very little jitter. Its cost is that the processor is busy checking even when nothing happens, wasting cycles, and its responsiveness is capped by how often it can poll while doing its other work.
Interrupt-Driven I/O
Interrupts let the processor do other work until the event arrives, then divert immediately to handle it. This is efficient for infrequent events and gives fast response without constant checking. The cost is interrupt latency and its variability, plus the complexity of concurrency: an interrupt can preempt other work at unpredictable moments, complicating worst-case analysis.
- Polling: predictable, simple, wastes cycles, good for very high-rate or dedicated loops
- Interrupts: efficient, responsive, add jitter and concurrency complexity
- Hybrid: interrupt to wake, then poll a burst of data before sleeping again
Choosing Between Them
High-rate, continuous data often favors polling or a hybrid: at very high rates the overhead of an interrupt per item exceeds the cost of a tight polling loop. Infrequent or bursty events favor interrupts, freeing the processor between events. A common hybrid uses an interrupt to signal that data is available, then polls to drain a batch, amortizing interrupt overhead while staying responsive.
Determinism Trade-Off
For the most timing-critical work, a dedicated polling loop on its own core can be more deterministic than an interrupt, because it removes the variable interrupt-entry latency and the risk of preemption. This is one reason some real-time designs dedicate a core to busy-poll a critical input, accepting the wasted cycles in exchange for tight, jitter-free response, while using interrupts for everything less demanding.