Polling vs Interrupt-Driven I/O: What Is the Difference?
Polling vs interrupt-driven I/O compared: busy-waiting, ISRs, interrupt storms, and when each approach wins, with an OS interview walkthrough.
Expected Interview Answer
Polling is where the CPU repeatedly checks a device’s status register in a loop until it is ready, while interrupt-driven I/O lets the CPU do other work and relies on the device to signal the CPU via a hardware interrupt when it needs attention.
In polling, the CPU executes a busy-wait loop, reading the device’s status register over and over, which wastes CPU cycles whenever the device is not ready but guarantees minimal response latency once it is. Interrupt-driven I/O instead lets the CPU proceed with unrelated instructions after issuing a request, and the device hardware raises an interrupt line when it completes, causing the CPU to save its current context, run an interrupt service routine to handle the device, and then resume what it was doing. Polling is preferable for very fast devices where the wait is shorter than the cost of an interrupt and context switch, whereas interrupts are preferable for slow or unpredictable devices like keyboards or disks, since they avoid wasting cycles on idle checking. Real systems often blend both: modern network interface cards use interrupt coalescing or switch to polling under high load (as in Linux NAPI) to avoid interrupt storms overwhelming the CPU.
- Interrupts free the CPU to do useful work while waiting
- Polling gives lower latency for very fast, predictable devices
- Understanding both explains interrupt storms and NAPI-style hybrids
- Guides driver design decisions for different device speeds
AI Mentor Explanation
Polling is like a substitute fielder who keeps jogging over to check the scoreboard every few seconds to see if a wicket has fallen, wasting energy on every check that shows nothing new. Interrupt-driven I/O is like the same fielder staying focused on their position while the umpire’s whistle immediately calls them over the moment a wicket actually falls. The whistle-based approach lets the fielder do useful work between events instead of constantly glancing at the board. This is exactly the trade-off between busy-wait checking and event-driven notification.
Step-by-Step Explanation
Step 1
Polling loop
The CPU repeatedly reads a device status register in a tight loop, checking for a ready flag.
Step 2
Interrupt request issued
In the interrupt model, the CPU issues the I/O request and continues other work instead of looping.
Step 3
Hardware interrupt fires
The device asserts an interrupt line once it is ready, signaling the CPU asynchronously.
Step 4
ISR handles device
The CPU saves context, runs the interrupt service routine to service the device, then resumes prior work.
What Interviewer Expects
- A clear contrast between busy-waiting and asynchronous notification
- Knowing when polling is actually preferable (very fast devices)
- Understanding what an interrupt service routine (ISR) does
- Awareness of interrupt storms and hybrid approaches like NAPI
Common Mistakes
- Claiming interrupts are always strictly better than polling
- Not knowing polling can be more efficient for extremely fast devices
- Confusing an interrupt with a context switch triggered by the scheduler
- Not mentioning interrupt storms as a downside of pure interrupt-driven I/O under high load
Best Answer (HR Friendly)
“Polling means the processor keeps actively checking a device to see if it is ready, which wastes effort while nothing has changed. Interrupt-driven I/O flips that around: the processor moves on to other work and the device itself signals back the moment it needs attention, which is far more efficient except for devices so fast that the interrupt overhead itself becomes the bottleneck.”
Code Example
/* Polling: busy-wait until the device reports ready */
void polling_read(volatile unsigned *status_reg, volatile unsigned *data_reg, unsigned *out) {
while (!(*status_reg & DEVICE_READY)) {
/* CPU spins here, doing nothing else */
}
*out = *data_reg;
}
/* Interrupt-driven: request, return immediately, ISR does the rest */
void interrupt_read(struct device *dev) {
dev->request_data(); /* CPU is free right after this call */
}
void device_isr(void) {
unsigned value = read_data_register();
deliver_to_waiting_process(value);
ack_interrupt();
}Follow-up Questions
- When is polling actually more efficient than using interrupts?
- What is an interrupt storm and how do systems mitigate it?
- What does an interrupt service routine (ISR) do differently from a normal function?
- How does Linux NAPI combine polling and interrupts for network cards?
MCQ Practice
1. What is the main drawback of polling?
Polling spins the CPU in a loop checking status, burning cycles even when the device has nothing new to report.
2. What signals the CPU in interrupt-driven I/O?
The device hardware raises an interrupt line, which the CPU responds to asynchronously via an interrupt service routine.
3. When is polling generally preferred over interrupts?
If a device responds faster than the cost of taking an interrupt and context switch, polling can actually be more efficient.
Flash Cards
What is polling? — The CPU repeatedly checking a device status register in a loop until it is ready.
What is interrupt-driven I/O? — The device signals the CPU via a hardware interrupt when it needs attention, freeing the CPU meanwhile.
When is polling preferable? — For very fast devices where the wait is shorter than interrupt/context-switch overhead.
What handles a hardware interrupt? — An interrupt service routine (ISR) that services the device and then returns control.