If the CPU polls devices (checks repeatedly if they’re done), it wastes cycles when devices are slow. The CPU should be free to do other work while waiting for I/O, and only handle the device when it’s actually ready.
A special function that executes when a device raises an interrupt, allowing the CPU to respond asynchronously to I/O completion without busy-waiting.
- Device completes operation and raises an interrupt signal on the control bus
- CPU pauses current work, saves context (registers, program counter)
- CPU jumps to the interrupt handler (addressed by interrupt vector)
- Handler reads device status register to confirm completion
- Handler copies data from device buffer to memory (or vice versa)
- Handler wakes up any process waiting for this I/O
- CPU restores context and resumes previous work
- Runs in kernel mode with high priority
- Must execute quickly (other interrupts may be masked)
- Can’t block or sleep (would hang the system)
- Shares data with the interrupted process via kernel structures
- Built from: O Software Structure, Device Controller
- Builds into: O Request to Hardware Operation
- Related: O System, Polling, DMA
- Contrasts with: O Software (runs in user space, not in interrupt context)
- Interrupt handlers can’t allocate memory or sleep (leads to deadlock)
- Nested interrupts require careful stack management
- Lost interrupts (device interrupts before handler is registered) cause hangs
- Interrupt storms (too many rapid interrupts) can freeze the system