Interrupt (computer systems)

How interrupts work

When an interrupt occurs the processor suspends the active program, saves enough state so execution can later resume, and transfers control to a designated interrupt handler or service routine. The exact steps typically include: saving registers or program counter, identifying the source or vector of the interrupt, executing a short handler routine, and restoring state before returning to the interrupted code. The hardware and operating system coordinate to make this transfer fast and safe.

Types and characteristics

• Hardware vs software: A hardware interrupt comes from devices (for example, a keyboard press or a network card), while a software interrupt is generated by instructions or system calls.
• Synchronous vs asynchronous: Synchronous events (exceptions or traps) are caused by the current instruction; asynchronous events arrive independently of instruction timing.
• Maskable vs non-maskable: Some interrupts can be temporarily disabled (masked); others, often indicating critical faults, cannot be ignored.
• Vectored interrupts: Systems often use an interrupt vector table to map sources to handlers.

History and development

The concept of interrupts evolved as computers moved from simple batch processing to interactive systems. Early machines used polling—regularly checking device status—but this wasted CPU time. The adoption of interrupt-driven I/O and the development of interrupt controllers allowed machines to respond immediately to external activity, paving the way for responsive time-sharing, embedded controllers, and real-time systems.

Common uses and examples

Interrupts are central to many everyday tasks in computing. Typical triggers include a hardware device signaling completion of a data transfer, a periodic timer tick used for scheduling, or input from a user such as a keypress. They are also used for error conditions and exceptions, for example when a program divides by zero or accesses invalid memory. Interrupt-driven designs are common in operating systems, device drivers, embedded controllers, and real-time applications where prompt reaction to an event is required.

Notable distinctions and implementation notes

Interrupts differ from polling and from synchronous traps. Proper use requires careful management of latency, priorities, and reentrancy: handlers should be short, and contexts must be saved correctly to avoid corrupting the interrupted program. Many processors support nested interrupts, priority arbitration, and direct memory access (DMA) devices that reduce CPU involvement. Understanding interrupts is essential for system programming, driver development, and designing responsive or real-time systems.

Further reading

For practical examples and hardware details see processor manuals and operating system texts; for general introductions consult resources linked from: microprocessor basics, program flow control, signal handling, hardware interrupts, software interrupts, keyboard input, timer interrupts, I/O transfers, and event-driven design.