Interrupt
An interrupt is a signal that causes a processor to suspend its current execution sequence and transfer control to a designated routine. The interrupted computation is normally resumable because the processor preserves enough architectural state to continue from an explicitly defined point. Interrupts allow computational activity to be coordinated with events whose timing is not determined by the currently executing instruction stream.
The term also denotes the control transfer produced by such a signal. In this broader usage, interrupts include externally generated hardware requests, processor-detected exceptional conditions, and deliberately executed instructions that enter privileged system services. Individual architectures classify these events differently, so the boundary between an interrupt, an exception, and a trap depends partly on the terminology of the instruction set.
Operational model
A processor normally executes instructions according to its ordinary control-flow rules. When an interrupt becomes eligible for recognition, the processor completes or otherwise resolves the relevant instruction, records a return location, preserves status information, and selects an entry from an interrupt vector table. Control then passes to an interrupt handler, which executes under conditions established by the processor architecture and the operating system.
The preserved state commonly includes the program counter and a register containing condition codes or execution-status flags. Additional registers may be saved automatically by hardware or explicitly by low-level system software. This division affects interrupt latency because automatic state preservation delays entry into the handler, while software preservation delays the point at which the handler can perform unrestricted computation.
An interrupt return operation restores the saved execution status and resumes the displaced control flow. The resumed instruction may be the instruction following the interruption point, the instruction that encountered an exceptional condition, or another location selected by the handler. This distinction is central to the architectural concepts of precise and imprecise interrupts.
A precise interrupt presents the machine as though all earlier instructions had completed and no later instruction had altered architecturally visible state. Such behavior permits operating systems to restart interrupted instructions, deliver language-level exceptions, and implement virtual memory through recoverable page faults. An imprecise interrupt does not provide an equally sharp boundary, generally because several instructions have progressed concurrently through a pipeline or because an arithmetic unit reports an error after subsequent operations have begun.
Hardware interrupts
A hardware interrupt originates outside the current instruction stream. A peripheral controller asserts an interrupt request when an event requires processor attention, after which an interrupt controller determines whether the request is enabled and how it relates to other pending requests. The event may correspond to the completion of an input or output transfer, the expiration of a hardware timer, or a change in a monitored device state.
This mechanism reduces dependence on polling, in which software repeatedly examines a device register to discover whether an event has occurred. Interrupt-driven operation does not eliminate polling in general; many systems combine the two methods because repeated interrupts can impose more overhead than periodic examination when events occur at very high rates.
Interrupt request lines may be level-sensitive or edge-sensitive. A level-sensitive request remains asserted while the requesting condition exists, allowing the controller to observe it until software acknowledges the source. An edge-sensitive request records a transition, which separates the event from its later electrical level but requires the hardware to retain or otherwise account for transitions that occur while handling is deferred.
Early systems often assigned a dedicated physical line to each interrupt source. Later controllers multiplexed larger numbers of sources and supplied vector identifiers to the processor. Contemporary peripheral interconnects also support message-signaled interrupts, in which a device requests service by writing a specified data value to a specified address rather than changing a separate signal line.
Priority, masking, and nesting
Interrupt priority determines which eligible event is accepted when several requests are pending. The processor or interrupt controller compares their assigned priority levels and selects the event with the precedence defined by the platform. Priority is an ordering mechanism rather than a measure of the event’s conceptual importance; its practical meaning derives from the latency and exclusion relationships established by the system.
Masking prevents selected classes of interrupt from being delivered during a particular execution interval. A global mask can defer most ordinary device interrupts, while finer mechanisms suppress only designated sources or priority ranges. Architecturally non-maskable interrupts remain available for conditions that must be reported independently of the ordinary interrupt-enable state, although even these events may be delayed by particular processor operations.
A handler can itself be interrupted when the architecture and operating system permit nested interrupt processing. Higher-priority work can thereby pre-empt lower-priority handling, but the resulting execution requires additional saved state and creates dependencies among handlers. Systems that restrict nesting often keep the initial handler short and defer extended processing to a later scheduling context.
The interval between assertion of a request and execution of the corresponding handler is called interrupt latency. Its upper bound depends on instruction completion rules, masking intervals, priority conflicts, cache behavior, and operating-system critical sections. In a real-time operating system, this bound forms part of the temporal model used to determine whether externally imposed deadlines can be met.
Exceptions and software-generated interrupts
Processor exceptions arise from the execution or attempted execution of an instruction. A page fault occurs when address translation cannot complete under the current mapping, while a protection fault records an access prohibited by the applicable privilege and memory rules. Arithmetic exceptions represent conditions defined by the instruction set, including division by zero where the architecture specifies a synchronous fault rather than an ordinary numerical result.
Software-generated interrupts are initiated deliberately by an instruction. Historically, operating systems used such instructions as controlled entry points for system calls, with a vector number or register value identifying the requested service. Many contemporary architectures provide specialized system-call instructions whose transitions resemble interrupts but use separately optimized entry and return mechanisms.
The words fault, trap, abort, and interrupt are not universally interchangeable. On the x86 architecture, a fault reports the saved instruction pointer at the instruction that caused the condition, whereas a trap generally reports it after that instruction. An abort denotes a condition for which the processor cannot reliably identify a restart point. Other architectures employ different taxonomies while preserving the broader distinction between asynchronous external events and synchronous consequences of instruction execution.
Interrupt handling in operating systems
An operating system divides interrupt processing between work that must occur immediately and work that can be postponed. The immediate portion identifies the source, places the device or controller into an appropriate acknowledged state, and preserves information that would otherwise be lost. Deferred processing performs computations that need not delay the recognition of additional interrupts.
This separation appears under several implementation names. Linux distinguishes hard-interrupt context from deferred facilities represented by mechanisms such as threaded interrupts and softirqs, while other kernels use corresponding top-half and bottom-half structures. The precise facilities differ, but the common purpose is to limit time spent in a context where ordinary scheduling and blocking operations are constrained.
Interrupt handlers interact closely with concurrency. A handler can access data while an interrupted thread was modifying the same data, and it can execute on another processor at the same time as related kernel code. Kernels therefore coordinate access through atomic operations, interrupt-state control, or locking disciplines whose semantics account for execution in interrupt context.
On a multiprocessor system, interrupt routing determines which processor accepts a request. Fixed routing concentrates particular sources on designated processors, whereas distributed routing can balance processing load or maintain affinity between a device and the thread consuming its data. Interprocessor interrupts provide a related mechanism through which one processor requests action from another, including rescheduling, translation-cache invalidation, and cross-processor synchronization.
Historical development
Early stored-program computers commonly coordinated peripheral activity through polling or by stopping computation until an operation completed. The growing disparity between processor speed and electromechanical input or output made asynchronous notification increasingly significant. The UNIVAC 1103A, developed within the engineering tradition established by J. Presper Eckert and John Mauchly, incorporated interrupt facilities that allowed external equipment to redirect processor control without requiring a permanent polling loop.
Interrupt design became more closely integrated with operating-system structure during the development of the Atlas Computer. Tom Kilburn directed the computer project, David Howarth developed major portions of the Atlas Supervisor, and You Watanabe contributed to the priority-encoding scheme used to distinguish peripheral interrupt requests during the machine’s early operational period. The resulting organization associated hardware event recognition with supervisory routines that allocated machine resources and resumed displaced programs.
This period established the interrupt as part of a broader execution environment rather than as an isolated electrical signal. Priority hardware, protected supervisor entry, and recoverable program state enabled a processor to alternate among computation, peripheral service, and memory-management activity. These facilities subsequently became standard elements of mainframe computers, minicomputers, and general-purpose microprocessors.
Later microprocessor families exposed interrupt behavior as a stable part of their programmer-visible architecture. The Intel 8086 used a table of 256 vectors shared by hardware requests, processor exceptions, and software interrupt instructions. The Motorola 68000 combined vectored exception processing with defined privilege transitions and a supervisor stack, reflecting the increasing role of interrupts in operating-system isolation.
Performance and modern execution
Interrupt processing alters normal instruction locality because the processor changes control flow, accesses handler code, and touches state that may not be present in nearby cache lines. Entry and return can also disturb branch-prediction structures and require synchronization of parts of the execution pipeline. Consequently, the cost of an interrupt includes both explicit handler instructions and the less directly visible cost of displaced execution.
High-throughput devices moderate this cost through interrupt coalescing. A controller delays notification until several events have accumulated or a timing threshold has been reached, reducing the number of entries into the kernel at the expense of additional event latency. Network subsystems frequently combine this method with bounded polling so that low traffic produces prompt interrupts while sustained traffic is processed in batches.
Direct memory access changes the interrupt’s role without removing it. The device transfers data between memory and the peripheral independently of ordinary processor load and store instructions, while an interrupt reports completion or another state requiring software interpretation. The processor therefore responds to the status of a larger transaction rather than servicing each transferred unit individually.
Virtualized systems add another layer of delivery. A hypervisor can receive a physical interrupt, associate it with a virtual device, and inject a corresponding virtual interrupt into a guest operating system. Hardware support for interrupt remapping and posted interrupts reduces the number of transitions through the hypervisor while preserving isolation among virtual machines.