Polling and Interrupts
IB Syllabus: A1.3.4 – Evaluate the use of polling and interrupt handling
Table of Contents
- Key Concepts
- Worked Examples
- Quick Check
- Trace Exercise
- Spot the Error
- Fill in the Blanks
- Predict the Output
- Practice Exercises
- Connections
Key Concepts
What is Polling? (A1.3.4)
Polling is a technique where the CPU repeatedly checks (polls) a device’s status register to see if it needs attention. The CPU runs in a tight loop: check the device’s status, find nothing new, check again, over and over.
Think of it like repeatedly checking your phone for messages every few seconds instead of waiting for a notification sound.
- Simple to implement – just a loop that reads a status register
- Deterministic timing – the CPU checks at a known, predictable interval
- Wastes CPU cycles when nothing is happening – the CPU is busy checking even when no event has occurred
- Higher power consumption – the CPU never truly idles; it is always running the polling loop
Polling loop (pseudocode):
while true:
status = read(device_status_register)
if status == READY:
process_data()
// otherwise, keep checking...
A common exam mistake is describing polling as “the device signals the CPU.” That describes interrupts, not polling. In polling, the CPU initiates every check – the device is passive.
What is an Interrupt? (A1.3.4)
An interrupt is a signal sent from a device to the CPU when the device needs attention. Instead of the CPU constantly checking, the device says “I need you now” – like a doorbell that rings when someone arrives, so you do not have to keep checking the door.
- The CPU can perform other useful work until interrupted
- When an interrupt fires, the CPU stops its current task, handles the event, then resumes
- More efficient for infrequent or unpredictable events
- Lower power consumption – the CPU can enter a low-power idle/sleep state between interrupts
The special code that handles an interrupt is called an Interrupt Service Routine (ISR) (also known as an interrupt handler).
Interrupt Handling Sequence
When an interrupt occurs, the CPU follows a precise sequence to handle it safely and return to what it was doing before.
Normal execution
|
v
[Interrupt signal received]
|
v
CPU finishes current instruction
|
v
CPU saves state (registers, PC) to stack
|
v
CPU identifies interrupt source
|
v
Jump to Interrupt Service Routine (ISR)
|
v
ISR handles the event
|
v
Restore saved state from stack
|
v
Resume normal execution
Why must the CPU save state? The ISR will use the CPU’s registers for its own work. Without saving the original register values, the interrupted program’s data would be overwritten and lost. The stack provides a safe place to store and later retrieve these values.
The interrupt handling sequence is a high-value exam topic. You must be able to describe each step and explain why the CPU saves and restores state (to allow the interrupted process to resume exactly where it left off).
Comparison Table
| Criterion | Polling | Interrupts |
|---|---|---|
| Event frequency | Better for frequent, predictable events | Better for infrequent, unpredictable events |
| CPU overhead | High – CPU busy even when no events | Low – CPU free until event occurs |
| Power consumption | Higher – CPU always active | Lower – CPU can idle/sleep between events |
| Latency | Predictable (depends on poll interval) | Variable (depends on ISR execution time) |
| Predictability | Deterministic timing | Non-deterministic (interrupts can nest) |
| Security | Simpler – no unexpected code execution | More complex – ISR must be secure; risk of interrupt injection |
The IB syllabus asks you to evaluate polling vs interrupts – this means you must be able to argue for and against each approach in a given scenario, not just describe them.
When to Use Polling
Polling is the better choice in specific situations:
- High-frequency events – sensor reading every millisecond (e.g., real-time audio processing where data arrives at a constant, rapid rate)
- Predictable timing required – safety-critical systems where deterministic behaviour is essential (e.g., industrial process control)
- Simple embedded systems – microcontrollers where interrupt hardware is limited or absent
- Debugging – easier to trace execution without asynchronous interrupts disrupting the flow
When to Use Interrupts
Interrupts are the better choice when:
- Infrequent events – keyboard presses, mouse clicks, network packets (events happen rarely and unpredictably)
- Battery-powered devices – CPU can sleep between interrupts (smartphones, smartwatches, laptops)
- Multiple I/O devices – handling many devices efficiently without dedicating CPU time to polling each one
- Real-time responsiveness – immediate reaction to urgent events (e.g., emergency stop button on industrial equipment)
Real-World Scenarios
1. Smartphone
A smartphone uses interrupts for touch screen input, incoming notifications, and phone calls. These events are infrequent and unpredictable. If the phone used polling to check the touch screen thousands of times per second while idle, the battery would drain rapidly. Interrupts allow the CPU to sleep and wake only when needed.
2. Gaming PC
A gaming PC uses interrupts for keyboard and mouse input – the player presses keys infrequently relative to the CPU’s speed. The GPU uses Direct Memory Access (DMA) to transfer rendered frames to display memory and sends an interrupt to the CPU when the transfer is complete, rather than making the CPU wait.
3. Industrial Sensor Network
A factory uses polling for high-frequency temperature sensor readings taken every 100 milliseconds. The readings are continuous and predictable, and the system needs deterministic timing to detect dangerous temperature changes at exact intervals. Polling ensures the readings are taken at precisely known times.
4. Smartwatch Fitness Tracker
A smartwatch uses interrupts for the heart rate sensor (readings taken only periodically) and accelerometer wake-on-motion (the CPU sleeps until the user moves their wrist). This maximises battery life – the CPU can remain in a deep sleep state for seconds at a time, waking only when a sensor interrupt fires.
In exam questions, always consider the frequency of events and power constraints first. These two factors usually determine whether polling or interrupts is more appropriate.
Worked Examples
Example 1: Evaluate Polling vs Interrupts for a School Web Server
A school runs a web server that hosts exam results. During results day, the server receives thousands of requests per second. Outside results day, traffic is minimal – perhaps a few requests per minute.
During peak (results day): Polling might be better. Events are so frequent that the overhead of saving/restoring state for each interrupt (context switching) exceeds the cost of simply checking for new requests in a loop. The CPU would be handling events almost continuously anyway, so the “wasted cycles” of polling are minimal.
During normal operation: Interrupts are better. With only a few requests per minute, polling would waste the vast majority of CPU cycles checking an empty queue. Interrupts allow the CPU to handle other tasks (backups, updates) and respond only when a request arrives.
Conclusion: A hybrid approach works best – the server uses interrupt-driven I/O under normal load and switches to polling mode when traffic exceeds a threshold. This is actually how modern high-performance network drivers (e.g., Linux NAPI) work.
Example 2: Trace an Interrupt Handling Sequence
Scenario: A user presses a key while the CPU is executing Process A (a spreadsheet calculation at instruction 47).
| Step | What Happens | Detail |
|---|---|---|
| 1 | Keyboard controller sends interrupt signal | The hardware interrupt line is asserted on the control bus |
| 2 | CPU finishes current instruction | Instruction 47 of Process A completes normally |
| 3 | CPU saves Process A’s state | Registers (including PC = 48) are pushed onto the stack |
| 4 | CPU identifies interrupt source | Looks up the interrupt vector table to find the keyboard ISR address |
| 5 | CPU jumps to keyboard ISR | PC is set to the ISR’s memory address |
| 6 | ISR reads the key code | The ISR reads the scan code from the keyboard’s data register |
| 7 | ISR stores key in input buffer | The character is placed in the OS input buffer for the application to read later |
| 8 | CPU restores Process A’s state | Registers are popped from the stack; PC is restored to 48 |
| 9 | Process A resumes | Execution continues from instruction 48 as if nothing happened |
The key point: Process A has no idea it was interrupted. From its perspective, the CPU simply continued executing instruction after instruction without interruption.
Quick Check
Q1. What is the main disadvantage of polling?
Q2. What is an Interrupt Service Routine (ISR)?
Q3. Which approach is better for a battery-powered device?
Q4. Why is polling latency more predictable than interrupt latency?
Q5. In which scenario does polling outperform interrupts?
Trace Exercise
Process B is running when a disk I/O completion interrupt fires. Fill in what happens at each step of the interrupt handling sequence.
Interrupt Handling Trace
Process B is executing instruction 34 when the disk controller signals that a data transfer is complete. Trace the interrupt handling sequence by filling in the missing values.
| Step | Action | CPU State |
|---|---|---|
| 1 | Disk controller sends interrupt signal | |
| 2 | Running Process B | |
| 3 | Saving state | |
| 4 | Jump to disk ISR | |
| 5 | Running ISR | |
| 6 | Restoring state | |
| 7 | Resume Process B |
Spot the Error
A student wrote the following description of polling for their exam revision. One line incorrectly describes interrupts instead of polling. Click the line with the error, then pick the correct fix.
Pick the correct fix for this line:
Fill in the Blanks
Complete the following statements about polling and interrupt handling:
POLLING vs INTERRUPTS
=====================
In , the CPU repeatedly checks a device's status register.
When an interrupt fires, the CPU runs a special routine called an .
The CPU must its current state before handling an interrupt.
Polling is better for events that are and predictable.
Interrupts are better for -powered devices because the CPU can sleep.Predict the Output
A system has two devices:
- Keyboard: generates approximately 5 events per second
- Sensor: generates approximately 1000 events per second
Which device should use polling?
A laptop runs on battery. The user is reading a document -- there has been no typing or mouse movement for 30 seconds.
Which I/O handling approach lets the CPU save the most power during this idle period?
Practice Exercises
Core
-
Define and compare – Define polling and interrupt handling in your own words. Give one advantage of each approach.
-
Interrupt sequence – Describe the step-by-step interrupt handling sequence that occurs when a mouse click interrupt fires while the CPU is running a word processor. Name at least six distinct steps.
-
Polling scenarios – State two scenarios where polling is preferable to interrupts. For each, explain why polling is the better choice.
Extension
- Evaluate for three scenarios – For each of the following, evaluate whether polling or interrupts is more appropriate. Justify your answer with reference to event frequency, CPU overhead, and power consumption:
- (a) Keyboard input on a desktop computer
- (b) Temperature sensor readings in a nuclear reactor (readings every 50ms)
- (c) Network card on a busy web server receiving 10,000 packets per second
- Latency analysis – Explain why interrupt latency is less predictable than polling latency. In your answer, refer to the steps involved in interrupt handling and how they can vary in duration.
Challenge
-
Self-driving car evaluation – A self-driving car has multiple sensors: LIDAR (60 readings per second), cameras (30 frames per second), and an emergency brake button (pressed rarely, but must respond within 1 millisecond). For each sensor, evaluate whether polling or interrupts is more appropriate. Consider both performance and safety implications in your answer.
-
Exam-style 4-mark question – Compare and contrast polling and interrupt handling for managing keyboard input on a battery-powered laptop. Your answer should include: a definition of each approach, an evaluation of which is more appropriate for this scenario, and a justified conclusion. [4 marks]
Connections
- Prerequisites: OS Fundamentals – the OS manages device I/O through polling and interrupts
- Prerequisites: CPU Architecture – interrupts interact with the FDE cycle; the CPU saves/restores state via registers and the stack
- Related: Scheduling – interrupts can trigger context switches and rescheduling
- Forward: Multitasking (HL) – interrupt handling is essential for multitasking OS operation
- Forward: Control Systems (HL) – control systems use both polling and interrupts for sensor data acquisition