an interrupt
An interrupt is a tap on the shoulder that says 'stop what you are doing, something needs attention now.' Imagine you are writing a letter when the doorbell rings. You pause mid-sentence, note where you left off, go answer the door, deal with it, then come back and pick up exactly where you stopped. An interrupt is the doorbell of the CPU: an electrical signal, usually from a device, that makes the processor suspend its current program and switch to special code to handle the event.
Concretely, the mechanism is precise. A device controller asserts an interrupt line. After finishing the current instruction, the CPU automatically saves its essential state (at least the program counter and status flags), switches into kernel mode, and uses an interrupt number to index a table called the interrupt vector to find the address of the right handler, the interrupt service routine. It runs that handler, then restores the saved state and resumes the interrupted program as if nothing happened. Interrupts come in flavours: maskable ones the CPU can temporarily ignore (block) when it must not be disturbed, and non-maskable ones (for emergencies like imminent power failure) that always get through; and they carry priorities so that a more urgent interrupt can preempt a less urgent handler. The same hardware path also serves traps and exceptions — software-triggered interrupts such as a system call or a page fault.
Why it matters: interrupts are the heartbeat of a modern OS. They are how devices report completion without the CPU polling, how a timer interrupt lets the scheduler take the CPU back from a running process (the basis of preemptive multitasking), and how the kernel is entered for system calls and faults. Without interrupts, the CPU would have to constantly ask every device 'anything yet?'; with them, the machine can run useful work and react instantly when the world changes.
You are editing a document when a network packet arrives. The network card raises interrupt number 11; the CPU pauses your editor, jumps via the interrupt vector to the network handler, copies the packet, then resumes your editor on the very next instruction — all in microseconds.
The running program is paused, the event is handled, and execution resumes exactly where it stopped.
An interrupt is asynchronous — it can arrive between any two instructions — so handlers must save and restore state carefully and run fast; doing slow work inside one stalls everything else, which is exactly why work is split into a fast top half and a deferred bottom half.