A1.3.4 · Operating systems and control systems
Polling and interrupts
By the end you can
Evaluate polling and interrupt handling against event frequency, CPU overhead, power, predictability, latency and security, for real devices and systems.
The CPU is far faster than any device attached to it. A key press, a network packet or a finished disk read happens only now and then, and the CPU must find out when. There are two ways: keep asking, or wait to be told.
Polling: keep asking#
With , the CPU checks each device's status on a timetable: “anything for me? … anything for me?” It is simple to build and completely predictable. But most checks find nothing, and each one costs CPU time and keeps the processor awake. An event that happens just after a check waits until the next one.
Interrupts: wait to be told#
With an , the device sends a signal to the CPU (along the control bus, A1.1.1) the moment it needs attention. The CPU gets on with other work, or sleeps, until then. When an interrupt arrives:
Finish the current instruction
The CPU completes the instruction it is in the middle of (it checks for interrupts between instructions).Save its place
The program counter and the other registers are saved, so the interrupted work can carry on later exactly where it stopped.Run the handler
It runs the for that device: for a key press, read the key and pass it to the OS.Restore and resume
The saved registers are put back and the interrupted program continues, never knowing it was paused.
Interrupts have priorities, so an urgent one (a power failure) can interrupt a less urgent handler. Saving and restoring the state takes time, so every interrupt has a small overhead.
Polling
100 checks per second
- CPU time
- 0.20%
- Avg delay
- 5.47 ms
- Worst delay
- 9.30 ms
Interrupts
12 interrupts per second
- CPU time
- 0.06%
- Avg delay
- 0.05 ms
- Worst delay
- 0.05 ms
Interrupts use less CPU time here: events are rarer (12 a second) than the checks polling has to make. With these costs the break-even point is about 40 events a second.
The simulator shows the key trade-off. Polling's cost depends on time: so many checks a second, whatever happens. The cost of interrupts depends on the number of events. With the costs used here, interrupts are cheaper below about 40 events a second and polling is cheaper above it. Polling also never delays an event by more than one interval, which is the sense in which it gives controlled latency: slower on average, but with a known worst case.
Weighing them up#
| Factor | Interrupts | Polling |
|---|---|---|
| Event frequency | Best when events are infrequent or irregular: no time is spent while nothing happens. | Can be better when events are very frequent: one check can collect several, instead of an interrupt for each. |
| CPU overhead | A cost for every event: save the state, run the handler, restore. Grows with the number of events. | A cost for every check, whether or not anything happened. Constant, however few events there are. |
| Power source | Suits batteries: the CPU can sleep until it is woken. | The CPU must keep waking up to check, which drains a battery. Less of a concern on mains power. |
| Event predictability | Handles unpredictable events immediately, whenever they come. | Works well when events come at known, regular times, so checks can be timed to match. |
| Controlled latency | Fastest response. But if many interrupts arrive together, some wait, so the delay can vary. | An event waits until the next check: never more than one interval. Slower, but the worst case is known in advance. |
| Security | A faulty or malicious device can flood the CPU with interrupts (denial of service), so they must be limited. On the other hand, a security event (an intrusion alarm, a tamper switch) is handled the moment it happens. | Cannot be flooded, but an event waits until the next check, and checking too rarely may delay or miss an important one. |
In real systems#
- Keyboard and mouse: interrupts. Input is unpredictable and must appear instantly; polling would waste time and add lag. Both methods are in fact at work: a USB device cannot interrupt the CPU itself, so the computer's USB controller polls the mouse many times a second (a “1000 Hz” gaming mouse every millisecond) and interrupts the CPU only when the mouse has news. A simple kiosk or data-entry terminal that is idle most of the time may just poll its keypad, because a slightly slower response does not matter and the design is simpler.
- Network communications: interrupts, because packets arrive unpredictably. Under extreme loads, network drivers switch to polling, since an interrupt for every one of millions of packets a second would swamp the CPU.
- Disk input and output: interrupts. The CPU starts a read, works on something else, and the disk interrupts when the data is ready, instead of the CPU checking a slow disk thousands of times. A data logger that writes a reading to its card every ten minutes can simply check the card is ready before each write: the writes are rare and on a fixed timetable.
- Embedded systems: battery-powered sensors sleep and wake on an interrupt to save power. A simple device with one job that checks a sensor at a fixed rate (a thermostat reading the temperature once a second) may just poll.
- Real-time systems: a car's airbag controller must react to a crash within milliseconds, so the crash sensor raises a high-priority interrupt. A robot arm doing the same moves on a fixed cycle may poll its sensors at exact intervals, because the guaranteed timing matters more than the fastest possible response.
Check yourself
Polling and interrupts
Quick questions, made fresh every time and marked here. Do a few until they feel easy.
Exam practice
Paper 1-style questions
6 questions · 21 marks
Write your answer as you would in the exam, then show the mark points and tick each one your answer made. These are our own questions in the style of the exam, not past-paper questions.
1.Distinguish between polling and interrupt handling.
[2]Distinguish: Make the differences between two things clear.
2.Describe what happens when the CPU receives an interrupt.
[4]Describe: A detailed account: say what happens, step by step if it is a process.
3.Explain why interrupts are usually preferred to polling in a battery-powered sensor that reports only occasionally.
[3]Explain: Give reasons: say what happens AND why, or how one thing causes another.
4.Suggest a situation in which polling would be a better choice than interrupts, and justify your choice.
[2]Suggest: Put forward a sensible answer for the situation given, with a reason. There may be several good answers.
5.Explain the role of controlled latency in choosing between interrupt handling and polling for a real-time system.
[4]Explain: Give reasons: say what happens AND why, or how one thing causes another.
6.Evaluate the use of interrupts, rather than polling, to handle input from a laptop keyboard.
[6]Evaluate: Weigh the strengths against the weaknesses (or the benefits against the costs) and reach a judgement that you back up.
Past papers
Old exam questions on this topic
From HL Paper 1, May 2014 to November 2025. These papers were set on the previous syllabus, so the wording may differ from today's exam, but the topic is the same. Find the questions and markschemes in your school's past-paper pack.
| Paper | Question | Marks | About |
|---|---|---|---|
| May 2025 TZ2 | 11(d) | 2 | One difference between interrupts and polling |
| May 2023 TZ1 | 4 | 4 | Definition of an interrupt; using polling |
| November 2023 | 12(c) | 5 | What an interrupt is; how the processor handles it |
| November 2022 | 12(c) | 4 | OS functions; how it knows a device needs attention |
| November 2020 | 11(d) | 4 | Polling versus interrupts for card readers |
| May 2018 | 10 | 2 | What an interrupt does |
| May 2017 | 16(d) | 5 | Interrupts from sensors in a control system |
| November 2016 | 10(d) | 3 | Polling versus interrupts when sensors fail |
| November 2015 | 9(b) | 4 | Definition of an interrupt; when one occurs here |
| November 2014 | 8 | 2 | Definition of polling |
In a nutshell
- Polling: the CPU checks the device at regular intervals. Simple and predictable, but wastes CPU time and power when nothing is happening.
- Interrupts: the device signals the CPU when it needs attention; the CPU saves its state, runs an interrupt service routine (ISR), then resumes.
- Event frequency: rare or unpredictable events suit interrupts; very frequent, regular events can suit polling.
- Overhead: polling costs CPU time all the time; interrupts cost time per event (saving and restoring state).
- Power: interrupts let a battery device sleep between events. Latency: interrupts respond almost at once; polling delays an event by up to one interval, but that delay is predictable.
- Security: a flood of interrupts can overwhelm the CPU (denial of service); polling too slowly can miss or delay important events.