Interrupts

How Hardware Gets the CPU's Attention

Imagine you're in a meeting, focused on your work. Someone taps you on the shoulder to tell you something important. That tap is an interrupt — a signal that tells the CPU to stop what it's doing and handle something urgent.

Interrupts are the primary mechanism by which hardware devices communicate with the CPU. Instead of the CPU constantly checking whether a device needs attention (polling), the device sends a signal when it has something to report.

Types of Interrupts

There are two main types of interrupts:

• Hardware Interrupts — Generated by hardware devices. When you press a key, the keyboard sends an interrupt. When a network packet arrives, the network card sends an interrupt. These are asynchronous — they can happen at any time.
• Software Interrupts (Traps) — Generated by the CPU itself during program execution. A system call is a software interrupt — the program explicitly requests OS services. A division by zero or an invalid memory access also generates a trap. These are synchronous — they're caused by the program's own execution.

How Interrupts Work

When an interrupt occurs, the following steps happen:

1. The device sends an interrupt signal to the CPU through an interrupt controller (a hardware chip).
2. The CPU finishes its current instruction, saves the current process's state (program counter, registers) into the PCB.
3. The CPU looks up the interrupt in the interrupt vector table — a table of function pointers that tells it where the appropriate interrupt handler (also called an ISR — Interrupt Service Routine) is located.
4. The CPU jumps to the interrupt handler, which runs in kernel mode.
5. The handler processes the interrupt (reads data from the device, handles the error, etc.).
6. The handler signals the OS that the interrupt has been handled.
7. The OS restores the previous process's state and resumes its execution.

All of this happens in microseconds. The interrupted process doesn't even know it was paused.

Nested Interrupts

What happens if an interrupt occurs while an interrupt handler is already running? Some systems allow nested interrupts — higher-priority interrupts can interrupt lower-priority handlers. This ensures that the most critical events are handled immediately.

Other systems disable interrupts while a handler is running to prevent complications. This is simpler but means that a long-running interrupt handler could delay other important interrupts.

The decision depends on the system's requirements. Real-time systems often allow nesting to ensure critical events are never delayed.

Interrupts vs. Polling

Why not just poll everything? The answer is efficiency:

• Interrupts — The CPU only deals with devices when they have something to report. Most of the time, the CPU can focus on running programs.
• Polling — The CPU wastes cycles checking devices that usually have nothing to say. With hundreds of devices, this overhead becomes significant.

That said, polling isn't useless. For very fast devices that produce data continuously (like some high-speed network cards), polling can be more efficient than interrupt overhead. Many systems use a hybrid approach — polling for fast devices, interrupts for slow ones.