Polling and Interrupts are an interesting and important discussion. Let’s break down the differences between polling and interrupts. These two terms are commonly used in the context of computer science and Embedded Systems, particularly in relation to how a computer’s central processing unit (CPU) communicates with its peripheral devices (like sensors, actuators, other MCUs, etc.) or handles certain software events.
Polling:
Polling is a technique where the CPU repeatedly checks the status of a device or software event to see if it needs servicing, i.e., if it has any tasks that need processing.
Consider a simple example: You’re waiting for a friend at a café. While waiting, you constantly look at the entrance to see if your friend has arrived. This is similar to polling – the CPU keeps ‘looking’ or checking if a device needs attention.
There are two types of polling: hardware polling and software polling. In hardware polling, the hardware checks if any device requires its attention. In contrast, software polling is where the software (usually an operating system) checks the status of operations or devices.
Pros and cons of Polling:
Pros:
- It is simple and easy to understand.
- It can be appropriate in situations where events occur infrequently and predictably.
Cons:
- It can waste CPU time if the device does not need servicing because the CPU is continually checking the device status instead of performing other tasks.
- It can lead to ‘polling loops’ where the CPU gets stuck repeatedly checking a device and cannot move onto other tasks.
Interrupts:
Interrupts, on the other hand, is a technique where a device signals the CPU that it requires attention. So, the CPU doesn’t have to continuously check the device; instead, it can work on other tasks and attend to the device only when the device signals for attention.
Returning to the café example, instead of constantly watching the door for your friend, you engage in other activities (reading a book, checking your phone, etc.) and your friend taps you on the shoulder when they arrive. This is similar to an interrupt – the CPU can focus on other tasks and the device ‘taps it on the shoulder’ when it needs attention.
Like polling, interrupts also have hardware and software variants. A hardware interrupt is triggered by hardware devices, while a software interrupt is triggered by software programs.
Pros and cons of interrupts:
Pros:
- They are more efficient because the CPU can perform other tasks and doesn’t waste time checking devices that don’t need servicing.
- They can handle ‘asynchronous’ events that happen unpredictably since they don’t rely on the CPU checking them at specific times.
Cons:
- They can be more complex to implement as they require handling routines and managing interrupt priorities (which interrupts should be handled first if multiple interrupts occur at once).
- If not properly handled, too many interrupts can overwhelm the CPU, causing performance issues.
Polling vs. Interrupt
| Polling | Interrupt | |
| 1. Complexity | It is generally simpler to implement. The CPU only needs a loop that continuously checks if the device requires attention. | More complex to implement as they require interrupt handling routines, managing interrupt priorities, and dealing with potential race conditions. |
| 2. CPU Efficiency | Less efficient, especially when devices do not need servicing frequently. The CPU wastes cycles continuously checking the status of devices. | More efficient as the CPU can perform other tasks and only attends to the device when signalled, saving CPU cycles. |
| 3. Event Timing | Better suited for situations where events occur infrequently and at predictable times. The CPU can be programmed to check the device status at these specific times. | Better at handling asynchronous, unpredictable events. The device signals the CPU whenever it needs attention. |
| 4. Response Time | Response time may be slower, particularly if the CPU is currently checking other devices. The device must wait until it’s its turn to be checked. | Typically ensures quicker response times. As soon as the device signals an interrupt, the CPU can save its current task and attend to the interrupt. |
| 5. Overhead | There can be significant overhead if the CPU gets stuck in a polling loop, checking a device or set of devices. | Overhead is generally less but can increase if not handled correctly or if too many interrupts are being generated. Interrupt handling routines also introduce some overhead. |
| 6. Real-time Applications | Not ideal for real-time applications, especially those requiring instant response, as the CPU may be busy checking other devices. | Suitable for real-time applications as the CPU can immediately respond to the device that raised the interrupt. |
| 7. Risk of Missing Data | There’s a risk of missing data if the data arrives between the times the CPU checks the device. | There’s less risk of missing data as the device signals the CPU when it has data. |
Latency in polling and interrupts:
Latency in computer systems refers to the time delay between a stimulus (like a keystroke or mouse click) and the response to that stimulus. In the context of interrupts and polling, latency can be considered as the time it takes for the system to react once a device is ready to be serviced.
Polling:
In polling, the latency can vary considerably. If the CPU just checked a device and then the device becomes ready to be serviced, the CPU won’t know until the next time it checks the device. So, if the CPU is checking multiple devices or is busy with other tasks, there can be a significant delay before it gets back to check the device again. The latency in a polling system is thus dependent on the polling rate and the number of devices being polled.
Interrupts:
In an interrupt-driven system, the latency is generally much lower. As soon as a device is ready to be serviced, it sends an interrupt to the CPU, which can then immediately save its current task and attend to the device. The latency in an interrupt system is primarily influenced by the time it takes to service other interrupts (if multiple interrupts occur at the same time, they may be put into a queue) and the time it takes to context switch (save the current task and start the interrupt service routine).
So, in terms of latency:
- Polling can have high and variable latency depending on the polling rate and the number of devices being polled.
- Interrupts generally offer low and consistent latency, provided the system is not overwhelmed with too many interrupts.
It’s important to note that these are general principles and the actual latency in a real-world system can be influenced by a wide range of other factors, including the specific hardware and software design, the load on the system, and more.
Summary of polling and interrupts:
To summarise, polling and interrupts are two strategies for handling device and software event servicing. Polling is like repeatedly checking on something, while interrupts allow the CPU to be notified when attention is needed. While interrupts are generally more efficient, they can also be more complex to handle and manage.
These two methods represent a trade-off between complexity and CPU efficiency. In low-demand, predictable systems, polling might be an easier-to-implement solution. In contrast, for high-demand, unpredictable systems where CPU resources are at a premium, interrupts are often the more appropriate solution. It’s all about picking the right tool for the job!
I hope this gives you a good introduction to the concepts of polling and interrupts. It’s a fascinating area of computer science that underpins how computers work at a fundamental level.
Vivek is a Senior Embedded Engineer at Robert Bosch. He has been working on Embedded Systems for the past 10 years. He loves to share his knowledge and train those who are interested. Nerdyelectronics.com was started out of this interest.
