A computer processor performs instructions at very high speed, but it does not work alone. It must also respond to keyboards, storage devices, network adapters, timers, software requests, and system errors. These events do not always happen at predictable moments. Interrupts allow the processor to react when attention is required.
An interrupt is a signal that asks the processor to pause its current activity and handle a specific event. After the event has been processed, the processor can usually return to the task it was performing before the interruption.
Interrupts are a basic part of modern computer systems. They support user input, network communication, operating system scheduling, hardware control, and error handling. Understanding them helps beginners see how hardware and software coordinate their work.
What Is an Interrupt?
An interrupt is a notification sent to the processor when an event requires attention. The event may come from a physical device, a software instruction, or a condition detected inside the processor.
For example, a keyboard may generate an interrupt when a user presses a key. A network adapter may generate one when new data arrives. A system timer may send regular interrupts so the operating system can manage time and switch between programs.
When the processor receives an interrupt, it temporarily changes its normal execution flow. It saves enough information to continue the current task later and transfers control to a special piece of code designed to handle the event.
This code is commonly called an interrupt handler or Interrupt Service Routine.
Why Computer Systems Need Interrupts
Without interrupts, the processor would often need to check every device repeatedly to see whether anything had happened. This approach is known as polling.
Imagine that the processor needs to monitor a keyboard. With polling, it may repeatedly ask, “Has a key been pressed?” Most checks would produce no useful result because users do not press keys every processor cycle.
Interrupts provide a more efficient alternative. The processor can continue performing other work while the keyboard remains inactive. When a key is pressed, the keyboard controller sends a signal.
This approach reduces wasted processor time and allows the system to respond quickly to unpredictable events. It is especially useful when many devices need attention at different moments.
A Simple Real-World Analogy
Consider a person working at a desk. Instead of repeatedly walking to the front door to check whether someone is there, the person relies on a doorbell.
The doorbell acts like an interrupt. When nobody is at the door, the person continues working. When the bell rings, the person pauses, remembers where the work stopped, responds to the visitor, and then returns to the original task.
A computer follows a similar process. The processor does not need to monitor every device continuously. Devices can signal when they require service.
The analogy is not perfect because processors handle interrupts through precise hardware and software rules. However, it explains the main idea: an interrupt allows an important event to request attention without constant checking.
What Happens When an Interrupt Occurs?
The exact sequence depends on the processor architecture and operating system, but interrupt handling usually includes several basic steps.
- A device, program, or processor condition generates an interrupt.
- The processor completes or pauses its current instruction according to its architecture.
- The current execution state is saved.
- The processor identifies the correct interrupt handler.
- The handler performs the required work.
- The saved state is restored.
- The processor returns to the interrupted task.
The saved state may include the current instruction location, register values, processor flags, and other information needed to continue correctly.
From the user’s perspective, this process often appears immediate. The interruption may take only a very small amount of time.
What Is an Interrupt Service Routine?
An Interrupt Service Routine, commonly shortened to ISR, is the code that runs in response to an interrupt. It is also called an interrupt handler.
Each type of interrupt normally has a handler responsible for the relevant event. A keyboard handler may read information about a pressed key. A network handler may acknowledge received data. A timer handler may update the system clock or trigger process scheduling.
An ISR should usually perform only the work that must happen immediately. Long or complicated operations can delay the handling of other interrupts and reduce system responsiveness.
For this reason, many systems divide interrupt processing into two stages. The immediate handler performs a small amount of urgent work. Less urgent processing is postponed and completed later by the operating system.
Hardware Interrupts
A hardware interrupt is generated by a physical device or hardware controller. It tells the processor that an external event has occurred.
Common sources of hardware interrupts include:
- Keyboards and mice
- Network adapters
- Storage devices
- System timers
- Audio hardware
- USB devices
- Sensors and buttons in embedded systems
Suppose a storage device finishes reading requested data. Instead of forcing the processor to keep checking whether the operation is complete, the device can send an interrupt. The processor then runs the relevant handler and makes the data available to the waiting program.
Hardware interrupts are important because external events often occur independently of the instruction currently being executed.
Software Interrupts
A software interrupt is caused by a program rather than an external device. It may be triggered through a special processor instruction.
Historically, software interrupts were commonly used when programs needed to request services from the operating system. A program could trigger an interrupt to ask the system to read a file, display output, or allocate a resource.
The processor would transfer control from the application to operating system code. This controlled transition protected system resources and prevented ordinary programs from directly performing sensitive operations.
Modern processors often provide dedicated instructions for system calls rather than relying on traditional software interrupt mechanisms. However, the underlying purpose is similar: transfer control safely from a user program to privileged operating system code.
Internal Interrupts and Exceptions
Some events are detected inside the processor while it executes an instruction. These events are often called exceptions rather than hardware interrupts.
Examples include:
- Division by zero
- An invalid instruction
- Access to protected memory
- A missing memory page
- An arithmetic overflow on some systems
An exception is usually connected directly to the current instruction. If a program attempts to divide a value by zero, the processor detects the problem during that operation.
The operating system may stop the program, provide it with an error, load missing data into memory, or take another action depending on the exception.
Interrupts vs. Exceptions
Interrupts and exceptions both change the normal flow of execution, but they usually have different sources.
A hardware interrupt is typically asynchronous. It can arrive between instructions and may be unrelated to the program currently running. A network packet, for example, may arrive at almost any time.
An exception is typically synchronous. It occurs because of the instruction being executed. The same instruction under the same conditions usually produces the same exception.
Terminology varies between processor architectures and operating systems. Some technical materials use the word interrupt as a broad category that includes exceptions. Others use the terms more strictly.
Maskable Interrupts
A maskable interrupt is an interrupt that the processor can temporarily block or delay. The system may disable these interrupts while performing a short operation that must not be interrupted.
For example, an operating system may need to update shared data safely. It can briefly prevent certain interrupts from running until the update is complete.
Masking does not normally mean that the event is ignored forever. The interrupt may remain pending and be handled after interrupts are enabled again.
Interrupts should not remain disabled for too long. Extended delays can cause slow responses, lost data, or other system problems.
Non-Maskable Interrupts
A non-maskable interrupt, or NMI, is a high-priority interrupt that normal interrupt controls cannot easily block.
NMIs are generally reserved for serious events that require immediate attention. Examples may include critical hardware failures, memory errors, or watchdog timer events.
Because these events may indicate that the system is unstable, the handler may record diagnostic information, initiate recovery, or stop normal operation.
The exact purpose of a non-maskable interrupt depends on the hardware platform. Its main characteristic is that ordinary interrupt masking does not prevent it from being recognized.
Interrupt Priorities
Several interrupts may arrive close together. The system needs a way to decide which one should be handled first.
Interrupt priority assigns different levels of importance to different signals. A critical hardware error may have a higher priority than routine keyboard input. The higher-priority event can be handled first, while lower-priority interrupts wait.
Priorities help the system respond quickly to urgent conditions. However, poor priority design can create problems. If high-priority interrupts arrive constantly, lower-priority events may experience long delays.
Operating systems and embedded developers must choose priorities carefully. The decision depends on timing requirements, hardware behavior, and the consequences of delayed processing.
What Is an Interrupt Controller?
A computer may have many devices capable of producing interrupts. An interrupt controller helps organize these signals before they reach the processor.
The controller can receive interrupt requests, apply priority rules, block selected signals, and identify which device requires attention. It then communicates the appropriate request to the processor.
Modern systems often use advanced programmable interrupt controllers. Multicore systems may also route interrupts to specific processor cores.
Without an interrupt controller, managing many hardware signals would be more complicated. The controller provides a structured connection between devices and the CPU.
Interrupt Vectors
After an interrupt occurs, the processor must find the correct handler. An interrupt vector helps it locate the appropriate code.
An interrupt vector is usually a number or identifier associated with a specific interrupt. The processor uses this identifier to find the address of the matching handler.
The handler addresses may be stored in an interrupt vector table. Each table entry connects an interrupt type with the code that should respond to it.
For example, one vector may correspond to a system timer, while another may represent a keyboard controller or a processor exception.
How the CPU Saves Its Current State
The processor must remember what it was doing before it begins an interrupt handler. Otherwise, it would not be able to return to the interrupted program correctly.
The saved information often includes the program counter, which identifies the next instruction to execute. The processor may also save status flags and selected register values.
Some information is saved automatically by the hardware. Additional register values may be saved by the interrupt handler or operating system.
The stack is commonly used to store this execution state. When interrupt processing finishes, the saved values are restored. A special return-from-interrupt instruction then resumes the previous execution flow.
Interrupts and the Operating System
The operating system plays a central role in interrupt management. It installs handlers, communicates with device drivers, manages priorities, and coordinates deferred processing.
When a hardware interrupt occurs, the processor usually enters kernel mode and runs trusted operating system code. This prevents ordinary applications from directly controlling hardware or changing system-level interrupt settings.
The operating system may use interrupts to:
- Receive input from hardware
- Track time
- Schedule processes and threads
- Complete storage operations
- Process network traffic
- Handle hardware failures
Applications benefit from this work without needing to understand the exact hardware details. They interact with the operating system through standard interfaces.
Interrupts and Device Drivers
A device driver is software that allows the operating system to communicate with a hardware device. Interrupt handling is one of its important responsibilities.
When a driver is initialized, it may register a handler for the device’s interrupt. If the device generates a signal, the operating system directs execution to that handler.
The driver may read device status, acknowledge the interrupt, collect available data, and schedule further processing. It then informs other parts of the operating system that the operation has progressed or finished.
Driver bugs can cause serious interrupt problems. A handler may fail to acknowledge a device, run for too long, or access shared data incorrectly.
Timer Interrupts
A system timer generates interrupts at regular intervals. These timer interrupts allow the operating system to keep track of time and perform scheduled work.
Timer interrupts are especially important for multitasking. The operating system can use them to limit how long one process runs before another process receives processor time.
A timer interrupt may cause the scheduler to examine the currently running task. The scheduler can allow it to continue or replace it with another ready task.
Timers also support delays, timeouts, animations, performance measurements, and periodic system maintenance.
Interrupts and Multitasking
A single processor core can normally execute only one instruction stream at a time. However, an operating system can switch rapidly between many tasks, creating the experience that several programs are running simultaneously.
Timer interrupts help make this possible. When a timer signal arrives, the operating system can save the current process state and load the state of another process.
This operation is called a context switch. It allows the next process to continue from where it previously stopped.
Modern computers have multiple cores and can execute several tasks physically at the same time. Even so, interrupts and scheduling remain essential because each core still needs to manage many active processes.
Interrupts vs. Polling
Polling means repeatedly checking the state of a device or condition. Interrupt-driven operation allows the device to notify the processor when attention is needed.
Interrupts are often more efficient when events are infrequent or unpredictable. The processor can perform useful work instead of repeatedly checking an inactive device.
Polling can still be useful. It may be simpler for very small systems, predictable high-speed operations, or situations where interrupt overhead would be greater than the cost of checking.
Some systems combine both approaches. A network adapter may initially generate an interrupt when data arrives. Under heavy traffic, the system may temporarily switch to polling to process many packets efficiently without receiving an interrupt for every packet.
Interrupts vs. System Calls
A system call is a request from an application to the operating system. It may ask the system to open a file, create a process, send network data, or allocate memory.
Older systems often implemented system calls through software interrupts. The program executed a special interrupt instruction, and the processor transferred control to the kernel.
Modern systems may use dedicated system call instructions that are faster than traditional interrupt mechanisms. These instructions still perform a controlled transition from user mode to kernel mode.
Therefore, an interrupt is a general mechanism for changing execution in response to an event, while a system call is a specific request for an operating system service.
What Is Interrupt Latency?
Interrupt latency is the time between the arrival of an interrupt and the beginning of its handler.
Several factors can affect this delay. The processor may need to finish its current instruction. A higher-priority interrupt may already be running. Interrupts may also be temporarily disabled.
Low latency is important in systems that must react quickly. An industrial controller, medical device, or vehicle safety system may need to respond within a strict time limit.
General-purpose computers can accept more variation in interrupt timing, but excessive latency can still cause slow input, audio problems, missed data, or poor system performance.
Nested Interrupts
A nested interrupt occurs when a new interrupt is accepted while another interrupt handler is already running.
This may happen when the new event has a higher priority. The processor pauses the first handler, saves its state, and begins the higher-priority handler. After that work is complete, it returns to the earlier handler.
Nested interrupts can improve responsiveness to urgent events, but they also increase complexity. Every additional level requires more stack space and careful management of shared resources.
Some systems disable interrupt nesting entirely. Others permit it only for selected priority levels.
Common Problems With Interrupt Handling
Interrupt handling must be designed carefully because mistakes can affect the entire system.
Common problems include:
- Handlers that take too long to finish
- Interrupts that are not acknowledged correctly
- Incorrect priority settings
- Unsafe access to shared data
- Too much work performed inside the handler
- Interrupts disabled for excessive periods
- Insufficient stack space for nested events
An interrupt handler may run at a sensitive system level where normal application rules do not apply. It may not be safe to perform operations that block, wait for another task, or use certain services.
Developers therefore keep handlers short and move complex work to normal threads or deferred processing mechanisms.
What Is an Interrupt Storm?
An interrupt storm occurs when a device or system component generates an extremely large number of interrupts within a short period.
The processor may spend most of its time entering and leaving handlers instead of performing useful application work. System performance can fall sharply.
An interrupt storm may be caused by faulty hardware, a driver error, incorrect configuration, or an event source that has not been cleared properly.
Operating systems may temporarily disable the problematic interrupt, limit its processing, or report a hardware or driver failure. Developers may also use batching and polling techniques to reduce interrupt frequency during periods of heavy activity.
Interrupts in Embedded Systems
Interrupts are especially important in embedded systems and microcontrollers. These devices often need to react to buttons, sensors, timers, communication interfaces, and changes in electrical signals.
For example, a microcontroller may spend most of its time in a low-power state. A sensor interrupt can wake it only when new data becomes available. This saves energy and extends battery life.
Embedded developers usually keep ISR code minimal. The handler may record a value or set a flag. The main program then performs the larger task outside the interrupt context.
Shared variables must be handled carefully because they can be changed by both the main program and the interrupt handler.
Interrupts in Real-Time Systems
A real-time system must respond to events within defined timing limits. Correct output is not enough if it arrives too late.
Interrupt priorities and latency are therefore critical. Events connected to safety or physical control usually receive higher priority than routine background work.
In a hard real-time system, missing a deadline may cause a serious failure. In a soft real-time system, occasional delays may reduce quality but not make the system unusable.
Developers analyze the maximum possible interrupt delay, handler execution time, nesting depth, and scheduling behavior. Predictability is often more important than average speed.
Practical Example: Pressing a Keyboard Key
When a user presses a key, the keyboard hardware detects the action. Its controller records information identifying the key and sends an interrupt request.
The processor temporarily pauses its current task and runs the keyboard interrupt handler. The handler reads the keyboard data and acknowledges the device.
The operating system then interprets the information. It considers the keyboard layout, modifier keys, and active application.
The resulting character or command is placed into an input queue. The active program later reads the event and responds, perhaps by displaying a letter on the screen.
This process happens quickly enough that typing appears immediate.
Practical Example: Receiving Network Data
When a network adapter receives a data packet, it stores the packet in memory or an internal buffer. It then signals the processor that new data is available.
The interrupt handler acknowledges the adapter and begins the necessary processing. In modern high-speed systems, the handler may schedule additional work instead of processing the entire packet immediately.
The operating system’s network stack examines the packet, checks its protocol information, and delivers the data to the correct application.
Without interrupts or a similar notification mechanism, the processor would need to check the network adapter constantly, even when no traffic was arriving.
Why Beginners Should Understand Interrupts
Interrupts connect several important areas of computing. They show how processors interact with hardware, how operating systems control devices, and how computers respond to events that occur at unpredictable times.
Understanding interrupts also makes other topics easier to study, including:
- Computer architecture
- Operating system scheduling
- Device drivers
- Input and output systems
- Embedded programming
- Real-time computing
- Concurrency and shared data
Beginners do not need to memorize every processor-specific rule. A useful starting model is that an event sends a signal, the processor saves its current state, a handler responds, and the original work later continues.
Conclusion
An interrupt is a signal that allows a processor to respond to an event without constantly checking for it. The event may come from hardware, software, a timer, or a condition detected during instruction execution.
When an interrupt is accepted, the processor saves its current state and runs an Interrupt Service Routine. After the handler finishes, the previous state is restored so normal execution can continue.
Interrupts support keyboards, networks, storage devices, system timers, multitasking, error handling, and embedded controls. They allow modern computers to coordinate many activities while using processor time efficiently.
Learning this concept gives beginners a clearer understanding of how hardware and software work together. It also provides a strong foundation for studying operating systems, computer architecture, and low-level programming.