Across several earlier chapters, we have mentioned interrupts in passing, from the interrupt check at the end of the instruction cycle, to the way a keyboard signals the CPU during interrupt-driven I/O. It is finally time to dedicate a full chapter to interrupts themselves, examining exactly what they are, how the CPU handles them, and how a system manages multiple interrupts competing for attention at once.
An interrupt is a signal that temporarily pauses the CPU's current activity, prompting it to immediately handle some other, usually more urgent, task before resuming what it was doing beforehand. Interrupts are what allow a computer to remain responsive to real-world events happening around it, rather than being permanently locked into finishing one single task from start to finish before ever reacting to anything else.
In this tutorial, you will learn about the difference between hardware and software interrupts, walk through the complete interrupt handling process step by step, understand the role of the interrupt vector table, and see how interrupt priorities are used to manage situations where multiple interrupts occur close together.
Without interrupts, a CPU would have no reliable way to respond quickly to unpredictable external events, such as a key being pressed, a mouse being moved, or a storage device completing a data transfer. The CPU would either need to constantly check for these events using busy waiting, wasting enormous amounts of processing time, or simply ignore them until it happened to reach a convenient point in its own program, causing noticeable delays.
Interrupts solve this problem elegantly by allowing external events to directly notify the CPU the moment they occur, letting the CPU continue with its normal work in the meantime, and only pausing briefly when something genuinely needs its attention.
A hardware interrupt is triggered by an external physical device, such as a keyboard, mouse, storage drive, or network adapter, signaling the CPU that it requires attention. Hardware interrupts are exactly the kind of interrupt we discussed in the interrupt-driven I/O chapter, allowing devices to notify the CPU only when they are actually ready, rather than being constantly polled.
CS Engineering Gyan's simulated system is running smoothly A viewer presses a key on the keyboard Keyboard hardware sends an interrupt signal directly to the CPU CPU detects this hardware interrupt and pauses its current task briefly to read and process the key press
A software interrupt, in contrast, is triggered intentionally from within a running program itself, rather than by an external device. Software interrupts are commonly used to request a service from the operating system, such as asking for a value to be printed to the screen, or requesting access to a particular system resource.
A running program needs to display a message on screen Program intentionally triggers a software interrupt, requesting the operating system's display service CPU pauses the currently running program momentarily Operating system's display routine handles the request, displaying the message on screen Program resumes normal execution afterward
Unlike hardware interrupts, which arrive unpredictably based on external events, software interrupts are deliberately placed within a program's own code, occurring at a specific, predictable point chosen by the programmer or compiler.
| Characteristic | Hardware Interrupt | Software Interrupt |
|---|---|---|
| Triggered By | An external physical device | A running program itself |
| Timing | Unpredictable, based on external events | Predictable, occurs at a specific point in the code |
| Typical Use | Signaling device readiness, like a completed I/O transfer | Requesting an operating system service |
Regardless of whether an interrupt is triggered by hardware or software, the CPU follows a broadly similar sequence of steps to handle it properly, ensuring that its original work can be safely resumed once the interrupt has been dealt with.
CPU is currently executing a program, working through its normal instruction cycle Step 1: An interrupt signal is detected, following the interrupt check we studied in the instruction cycle chapter Step 2: CPU finishes executing its current instruction completely, rather than stopping in the middle of it Step 3: CPU saves its current state, including the value of the Program Counter and relevant registers, typically onto a stack Step 4: CPU determines which specific interrupt occurred Step 5: CPU jumps to the appropriate Interrupt Service Routine, often abbreviated as ISR, associated with that particular interrupt Step 6: The ISR executes, handling whatever task the interrupt requires Step 7: Once the ISR finishes, the CPU restores its previously saved state from the stack Step 8: CPU resumes the original program exactly where it had left off, continuing as if nothing had happened
This careful process of saving and later restoring the CPU's state is exactly what allows the original program to resume seamlessly, completely unaware that an interrupt was ever handled in between.
An Interrupt Service Routine, commonly abbreviated as ISR and sometimes also called an interrupt handler, is a small, dedicated block of code specifically written to handle a particular type of interrupt. Every distinct interrupt a system supports typically has its own corresponding ISR, tailored to whatever specific task that interrupt requires.
Keyboard interrupt occurs CPU locates the ISR specifically written to handle keyboard interrupts This particular ISR reads the character value from the keyboard's data register and stores it for the running program to use Once this task is complete, the ISR finishes, and control returns back to the interrupted program
Since a computer system typically supports many different types of interrupts, from a keyboard press to a completed disk transfer, the CPU needs a reliable way to determine exactly which ISR corresponds to each specific interrupt. This is exactly the role of the interrupt vector table, a structure that maps each type of interrupt to the memory address where its corresponding ISR begins.
Simplified interrupt vector table Interrupt Type 0 (Keyboard) → ISR located at address 8000 Interrupt Type 1 (Timer) → ISR located at address 8200 Interrupt Type 2 (Disk) → ISR located at address 8400 A keyboard interrupt occurs CPU looks up Interrupt Type 0 in the interrupt vector table, finds the address 8000, and jumps directly there to begin executing the correct ISR
Without the interrupt vector table, the CPU would have no organized, efficient way of quickly locating the correct ISR every time a different type of interrupt occurred, especially in systems that support a large number of distinct interrupt sources.
In situations where multiple interrupts occur at nearly the same time, or where a new interrupt arrives while an existing ISR is still running, the CPU needs a way to decide which interrupt deserves attention first. This is managed through interrupt priorities, where different interrupt sources are assigned different priority levels, generally allowing more urgent interrupts to take precedence over less urgent ones.
CPU is currently handling a lower-priority timer interrupt A higher-priority disk interrupt occurs, signaling that important data has just become available Because the disk interrupt has a higher priority than the timer interrupt currently being handled, the CPU pauses the ongoing timer ISR and immediately switches to handle the higher-priority disk interrupt first Once the disk interrupt has been fully handled, the CPU returns to complete the interrupted timer ISR
This kind of priority-based handling ensures that especially urgent or important interrupts are not left waiting unnecessarily behind less critical ones, helping the overall system remain responsive to the events that matter most at any given moment.
Some interrupts, called maskable interrupts, can be temporarily disabled or ignored by the CPU under certain conditions, such as while it is busy handling another especially critical task. Other interrupts, called non-maskable interrupts, cannot be disabled or ignored under any circumstances, since they typically represent extremely urgent situations, such as a critical hardware failure, that must always be handled immediately regardless of what the CPU is currently doing.
CPU is currently handling a critical, high-priority task and has temporarily disabled maskable interrupts A routine hardware interrupt occurs, but since it is maskable and interrupts are currently disabled, the CPU ignores it for now A non-maskable interrupt occurs, signaling a serious hardware issue Because this interrupt is non-maskable, the CPU immediately pauses its current task to handle it, regardless of its earlier decision to disable maskable interrupts
| Advantages | Limitations |
|---|---|
| Allows the CPU to remain responsive to external events without wasting time on busy waiting. | Handling an interrupt introduces some overhead, since the CPU must save and later restore its state. |
| Interrupt priorities ensure the most urgent tasks are handled first. | Poorly managed interrupt priorities can cause lower-priority tasks to be delayed excessively. |
| The interrupt vector table allows fast, organized access to the correct ISR for each interrupt type. | Systems supporting many interrupt sources require careful design to avoid conflicts and confusion. |
| Mistake | Correct Practice |
|---|---|
| Confusing hardware interrupts with software interrupts. | Remember that hardware interrupts come from external devices, while software interrupts are triggered from within a running program. |
| Assuming the CPU stops mid-instruction the moment an interrupt occurs. | Remember that the CPU typically finishes its current instruction before handling an interrupt. |
| Forgetting that the CPU's state must be saved before running an ISR. | Remember that saving the Program Counter and relevant registers is essential to resuming the original program correctly afterward. |
| Assuming all interrupts can always be disabled or ignored. | Remember that non-maskable interrupts cannot be disabled, since they represent extremely urgent situations. |
Interrupts allow a CPU to remain responsive to important events, whether triggered externally by hardware devices or intentionally from within running software, without needing to waste processing time constantly checking for them. The interrupt handling process carefully saves the CPU's current state, executes the appropriate Interrupt Service Routine located through the interrupt vector table, and then restores everything so the original program can resume exactly where it left off.
We also saw how interrupt priorities help manage situations where multiple interrupts compete for attention, and how non-maskable interrupts guarantee that especially urgent events, such as critical hardware failures, are always handled immediately. Together, these mechanisms tie directly back to the interrupt check we first introduced in the instruction cycle chapter and the interrupt-driven I/O strategy covered in the previous chapter, completing the full picture of how interrupts function within a computer system.
With interrupts covered, you are now ready to explore pipelining, where we will look at how modern CPUs process multiple instructions simultaneously by overlapping their individual stages, significantly improving overall instruction throughput.