Interrupts (OS)
The kernel's view: interrupt context, bottom halves, and why you cannot sleep in a handler.
Level: intermediate
What is it?
An interrupt is an event that causes the processor to transfer control to a configured handler. Hardware interrupts commonly report device events or timers; exceptions arise from the current instruction, and software traps support defined transitions such as system calls.
Why does it matter?
Interrupts let the kernel respond to asynchronous events without continuously polling every device. Handling must be fast and carefully synchronized because it can interrupt code at inconvenient points.
Mental model
Think of an interrupt as a doorbell to privileged code. The handler acknowledges or records the immediate event, then often schedules deferred work for operations that can take longer.
How it works
- Interrupt handlers execute under architecture- and kernel-specific context rules and may have restricted operations available.
- Short handlers reduce latency for other interrupts and avoid holding the CPU in an urgent context.
- Deferred work performs longer processing outside the immediate handler when the kernel design supports it.
- Interrupt masking, priorities, and affinity influence response time and ordering.
- Interrupt handlers are distinct from POSIX signals delivered to user processes, despite similar names.
Steps
- A device raises an interrupt when an I/O operation completes.
- The CPU saves appropriate execution state and enters the registered handler.
- The handler acknowledges the interrupt, captures essential state, and schedules additional work if needed.
- The kernel resumes interrupted execution or schedules another ready thread.
Real-world usage
- Explaining timers, device completion, and preemptive scheduling.
- Debugging high interrupt rates and latency issues.
- Distinguishing hardware interrupts from process signals and system calls.
Common mistakes
- Doing unbounded work in a handler and increasing interrupt latency.
- Sleeping or acquiring a blocking lock in a context that cannot safely sleep.
- Confusing a process signal such as SIGTERM with a hardware interrupt.
Interview questions
Why should an interrupt handler usually be short?
Long handling delays other events and increases system latency; complex work is often deferred to a safer execution context.
Are POSIX signals the same as hardware interrupts?
No. A hardware interrupt is a processor/kernel event typically caused by hardware; a POSIX signal is a software notification delivered to a process or thread under OS rules.