A1.3.4 Evaluate the use of polling and interrupt handling.
• Event frequency, CPU processing overheads, power source (battery or mains), event predictability, controlled latency, security concerns
• Real-world scenarios may include keyboard and mouse inputs, network communications, disk input/ output operations, embedded systems, real-time systems
The big idea
There are two fundamental strategies for detecting external events:
- Polling – the CPU repeatedly checks a status register or memory location to see whether something happened.
- Interrupt handling – the external device asserts a signal that asynchronously diverts the CPU to a service routine when the event occurs.
Choosing between them is an engineering trade-off that centres on how often the event occurs, how tight the latency budget is, and how expensive each check or context switch will be.
It may be helpful to review units of time table at this link.
Comparison
| Criterion | Polling | Interrupt handling |
|---|---|---|
| Event frequency | Suits high-rate or continuous streams where an event is almost always ready (e.g., 100 Gbit s⁻¹ packet capture, graphics scan-out). A busy loop wastes little extra work if the flag is usually set. | Best for sparse or bursty events (e.g., key presses, USB hot-plug) so the CPU can sleep between arrivals. |
| CPU overhead | Each poll executes a branch and possibly a bus transaction even when nothing happened, so overhead scales with polling rate. | Overhead is amortised: none while idle; a context switch and ISR prologue on each interrupt. |
| Power consumption | Continuous polling prevents deep sleep states—undesirable on battery-powered devices. | Allows the core to remain in low-power C-states until the interrupt fires; advantageous for mobile and IoT. |
| Event predictability | Latency is deterministic: at most the time between successive polls. The software designer can pick a polling period that meets a hard deadline. | Latency depends on interrupt masking, priority, and ISR length. Generally low, but bounded only by worst-case interrupt latency of the platform. |
| Controlled latency | Minimum latency = 0 (if you poll tight); maximum latency = polling interval. Good for hard real-time if the interval can be made short enough without overheating the CPU. | Usually low (≈ µs–tens of µs on desktops) but subject to jitter from other interrupts and critical sections; may need priority management for real-time. |
| Security surface | Pure polling has no asynchronous control transfers, so fewer chances for interrupt vector hijacking or ISR stack smashing. | Adds a privileged entry point per vector; bugs in ISRs or interrupt controllers widen the attack surface (e.g., “Thunderclap” DMA attacks, spurious-interrupt DoS). |
| Typical software patterns | Tight while-loops in firmware, NIC “busy-poll” modes (NAPI, DPDK), GPU spin-waits, RAID checksum offload loops in the kernel. | Bottom-half handlers in OS kernels, signal-driven user I/O (select/epoll awakenings), GPIO or timer interrupts in MCUs. |
Real-world scenarios
| Scenario | Why one method dominates | Notes |
|---|---|---|
| Keyboard and mouse on a laptop | Interrupts – human input is infrequent; waking on each key saves battery. | Gaming keyboards may add optional high-rate polling (≈ 1 kHz) on mains-powered PCs for sub-millisecond latency. |
| High-speed network interfaces (10–400 GbE) | Hybrid – start with an interrupt, then switch to adaptive polling (NAPI “poll mode”) while the ring buffer stays above a threshold. | Reduces interrupt storms under load while avoiding wasted cycles when idle. |
| NVMe SSD I/O | Interrupts for normal workloads; pure polling for tail-latency-critical datacentres (e.g., SPDK user-space drivers). | Polling avoids the cost of interrupt delivery and context switches when thousands of I/O completions per core are pending. |
| Small embedded sensor node | Polling inside a tight loop when the device has no MMU and runs a single control task at 100 Hz. | If energy is critical, designers often use timer interrupts to wake, poll quickly, then sleep again. |
| Hard real-time motor control (PLC, flight computer) | Polling or timer-driven cyclic executive for the control loop; asynchronous interrupts disabled during the critical section. | Guarantees that no interrupt jitter violates control-law deadlines. |
When to choose which
Prefer polling when:
- The event rate is high enough that most polls succeed (≈ > 50 % hit ratio).
- You need a strictly bounded latency shorter than the platform’s worst-case interrupt latency.
- The CPU would be awake anyway (server core already pinned to 100 % utilisation).
Prefer interrupt handling when:
- Events are sparse or bursty, so wasted polls would dominate.
- Battery life or thermal headroom matters.
- Security auditors require minimal privileged code paths in the main loop.
Putting it together
Modern systems seldom commit exclusively to one style. Instead they blend both techniques, using interrupts to wake up a driver and then switching to short bursts of busy polling while a queue is non-empty. This adaptive approach balances power, throughput and latency across a wide dynamic range—one of the many places where operating-system design is an exercise in finding the “just right” point on several competing curves.