An interrupt is a mechanism that allows a computer system to draw the CPU's attention to an event that needs to be handled. The event may originate from a hardware device, a timer, or software currently executing on the processor.
Instead of forcing the CPU to continuously check every device, an interrupt allows the source of the event to notify the processor when attention is required. The CPU can therefore spend most of its time executing useful instructions and temporarily change its control flow when an interrupt is accepted.
Interrupts are closely related to input-output organization and the instruction cycle. They are particularly important in systems where events can occur at unpredictable times, such as keyboard input, network activity, timer events, or completion of an I/O operation.
An interrupt is a request or signal that causes the processor to temporarily suspend its normal program execution and transfer control to a special piece of code called an Interrupt Service Routine (ISR).
After the required interrupt-handling work is completed, the processor restores the necessary execution state and returns to the interrupted program.
A simple way to understand the idea is:
Normal Program
↓
Interrupt Occurs
↓
CPU Accepts Interrupt
↓
CPU Saves Required State
↓
Interrupt Service Routine (ISR)
↓
CPU Restores State
↓
Normal Program Continues
The exact hardware mechanism differs between processor architectures, but the basic purpose remains the same: respond to an important event without permanently changing the current program's execution.
I/O devices operate independently of the CPU and may require attention at times that cannot be predicted by the currently running program. If the processor had to repeatedly inspect every device to determine whether something had happened, a considerable amount of CPU time could be spent checking devices rather than performing useful computation.
This method of repeatedly checking a device is known as polling. Interrupts provide another approach in which the device or system component requests CPU attention when an event occurs.
For example, a keyboard does not need to be checked thousands of times per second merely to discover whether a key has been pressed. When a key event occurs, the keyboard interface can generate an interrupt and allow the processor to handle it.
Interrupts can be classified in several ways. Two commonly studied classifications are based on their source and on whether the processor can temporarily disable them.
A hardware interrupt originates from a hardware component or an external device. The device uses an interrupt mechanism to request service from the processor.
Typical sources include:
For example, when a device completes an I/O operation, it can notify the CPU through an interrupt rather than requiring the CPU to continuously check the device status.
A software interrupt is generated by software execution rather than by an external hardware device. It can be used to deliberately transfer control to a predefined operating-system or processor service.
Historically, software interrupt instructions have been used for system calls and other controlled transitions from application code to privileged system code. Modern processors also provide dedicated instructions and mechanisms for system calls, so the exact implementation depends on the architecture and operating system.
| Feature | Hardware Interrupt | Software Interrupt |
|---|---|---|
| Source | Hardware device or controller | Instruction or software execution |
| Occurrence | Usually associated with an external event | Explicitly requested by software |
| Example | Timer or keyboard event | Software interrupt instruction |
| Purpose | Notify CPU about a hardware-related event | Request a predefined software or system service |
An Interrupt Service Routine (ISR) is the code executed by the processor to service a particular interrupt. It is also commonly called an interrupt handler.
The responsibility of an ISR depends on the source of the interrupt. A device-related ISR may read information from a controller, record the event, update a buffer, or notify another part of the operating system.
For example, when a network controller reports that a packet has arrived, its interrupt handler can begin the processing required to acknowledge the device and make the received data available to the operating system.
An ISR should generally perform the necessary urgent work efficiently. Lengthy processing can delay other interrupt requests and normal program execution.
When an interrupt is generated, the CPU does not simply abandon the instruction it is currently executing. The processor follows a defined mechanism for recognizing, accepting, and servicing the interrupt.
The exact registers saved and the way the handler address is obtained depend on the processor architecture. Therefore, this sequence should be understood as the general concept rather than as an identical procedure for every CPU.
A processor may have many different interrupt sources. It therefore needs a mechanism for determining where the handler for a particular interrupt is located.
An interrupt vector table is a table or related data structure containing information that allows the processor to locate the appropriate interrupt handler for a particular interrupt vector or interrupt number.
A simplified representation is:
Interrupt Vector Handler Address Vector 0 → Address of Handler 0 Vector 1 → Address of Handler 1 Vector 2 → Address of Handler 2 Vector 3 → Address of Handler 3 ...
When an interrupt is associated with a particular vector, the processor uses that vector to locate the corresponding handler.
The exact organization and name of this structure vary between architectures. The important idea is that the interrupt identification information provides a systematic way to transfer control to the correct handler.
Another important classification is based on whether an interrupt can be temporarily disabled by the processor.
A maskable interrupt is an interrupt that can be temporarily prevented from being accepted by the processor through an interrupt mask or related control mechanism.
This facility is useful when the processor or operating system needs to protect a critical section of execution from certain interrupt requests for a short period.
A non-maskable interrupt (NMI) is designed for events that require attention even when ordinary maskable interrupts have been disabled.
NMIs are commonly associated with serious hardware or system conditions. The exact use depends on the processor and system design.
| Feature | Maskable Interrupt | Non-Maskable Interrupt |
|---|---|---|
| Can be temporarily disabled? | Yes, through the appropriate interrupt-control mechanism | No, under the normal masking mechanism |
| Typical purpose | Routine device or system events | Critical conditions requiring special attention |
| Priority | Depends on the interrupt system | Generally treated as highly urgent |
A computer may receive interrupt requests from several sources. If multiple requests are pending, the system needs a method for determining which one should be serviced first.
This is the purpose of interrupt priority. Interrupt sources can be assigned different priority levels so that important events can receive service before less urgent requests.
For example, suppose a processor has pending requests from a routine timer and another device that requires immediate attention. A priority mechanism can determine the order in which these requests are handled.
Priority handling can be implemented using hardware interrupt controllers, processor mechanisms, or operating-system policies, depending on the system.
Interrupts can also be classified according to how the processor obtains the address of the interrupt handler.
In a vectored interrupt, information associated with the interrupt identifies a particular vector or handler location. The processor can therefore determine the appropriate service routine directly through the system's interrupt-vector mechanism.
In a non-vectored interrupt, the interrupt does not directly provide a unique handler address in the same way. Additional software or hardware logic may be required to determine which device generated the request and which service routine should be executed.
| Type | Handler Selection | Main Idea |
|---|---|---|
| Vectored Interrupt | Interrupt vector identifies the appropriate handler | Direct and organized handler selection |
| Non-Vectored Interrupt | Additional mechanism identifies the source and handler | Handler selection requires further identification |
Interrupt latency is the time between the occurrence of an interrupt request and the beginning of execution of the corresponding interrupt handler.
Low interrupt latency is particularly important in systems where events must be handled quickly. Several factors can affect latency, including the current CPU activity, interrupt masking, processor architecture, interrupt priority, and the time required to save the execution state.
Interrupt latency should not be confused with the total time required to complete the ISR. Latency describes the delay before interrupt handling begins, whereas the service time describes how long the handler takes to perform its work.
Interrupts and polling are two different methods of detecting events from devices.
| Feature | Polling | Interrupts |
|---|---|---|
| How event is detected | CPU repeatedly checks device status | Device or system signals the CPU |
| CPU activity while waiting | CPU spends time checking status | CPU can continue other work |
| Suitable situation | Simple or tightly controlled systems | Events that occur asynchronously or unpredictably |
| Main concern | Repeated checking can consume CPU time | Interrupt handling introduces processing overhead |
Neither method is universally superior. The appropriate approach depends on the processor, device, workload, timing requirements, and system design.
Interrupts are particularly important in I/O organization. A peripheral device can generate an interrupt when it needs CPU attention or when an operation has reached a particular state.
Consider a storage controller performing an I/O operation:
CPU starts an I/O operation
↓
CPU continues other work
↓
Storage controller performs the operation
↓
Operation completes
↓
Controller generates interrupt
↓
CPU executes the appropriate ISR
↓
Operating system processes the completion
This approach prevents the CPU from continuously waiting for the device.
For large data transfers, DMA can further reduce CPU involvement by moving data directly between an I/O device and memory. In such systems, the DMA controller can generate an interrupt after a transfer has completed.
An interrupt may occur while another interrupt handler is executing. Whether the new interrupt is accepted immediately depends on the processor's interrupt rules, priority system, and interrupt-control state.
If a higher-priority interrupt is permitted to interrupt a lower-priority handler, the system may temporarily suspend the first ISR and execute the higher-priority ISR.
Main Program
↓
Low-Priority ISR
↓
High-Priority Interrupt
↓
High-Priority ISR
↓
Return to Low-Priority ISR
↓
Return to Main Program
Interrupt nesting must be carefully controlled because excessive nesting can increase overhead and make the system more difficult to manage.
Suppose a computer is executing a program while a timer generates an interrupt.
The application program does not need to continuously inspect the timer merely to discover that the interval has expired. The interrupt mechanism provides the notification path.
| Term | Meaning |
|---|---|
| Interrupt | A mechanism that requests CPU attention for an event. |
| ISR | Interrupt Service Routine that handles an interrupt. |
| Interrupt Vector | Identifier used to locate or select an interrupt handler. |
| Interrupt Vector Table | Structure containing information used to locate interrupt handlers. |
| Interrupt Priority | Mechanism for deciding the order in which interrupt requests are serviced. |
| Interrupt Latency | Time between an interrupt request and the beginning of its handler. |
| Maskable Interrupt | Interrupt that can be temporarily blocked through interrupt-control mechanisms. |
| Non-Maskable Interrupt | Interrupt designed to remain serviceable even when ordinary interrupt masking is active. |
An interrupt normally causes a temporary change in control flow. After servicing the interrupt, the processor can return to the interrupted execution.
Interrupt mechanisms can also be invoked through software. Hardware interrupts and software-generated interrupts should therefore be distinguished by their source.
Polling requires the CPU to repeatedly check a status condition. Interrupt-driven operation allows the relevant source to request CPU attention.
Systems can use different priority levels to determine which pending interrupt should receive service first.
Interrupt handlers should be designed carefully because lengthy interrupt processing can delay other interrupts and normal program execution.
Interrupts provide an efficient mechanism for handling events that require processor attention. Instead of continuously checking devices, the CPU can execute normal programs and respond when an interrupt request is accepted.
The main concepts associated with interrupts include hardware and software interrupts, Interrupt Service Routines, interrupt vectors, interrupt priority, interrupt latency, and maskable and non-maskable interrupts. Vectored and non-vectored mechanisms describe different ways of identifying the appropriate interrupt handler.
Interrupt processing connects several important areas of computer organization. The instruction cycle explains when the processor can recognize an interrupt, I/O organization explains why devices need a way to notify the CPU, and DMA shows how hardware can perform large data transfers while minimizing CPU involvement.
A clear understanding of interrupts provides an important foundation for studying operating systems, CPU architecture, I/O systems, multitasking, and advanced processor design.