an interrupt
Instead of standing by the oven checking every ten seconds, you set a timer that rings when the cake is done, and you go read a book. The moment the bell rings you drop the book, take out the cake, and pick the book back up where you left off. An interrupt is that bell. It is a hardware signal a device sends to the CPU that says 'stop what you are doing for a moment, I need attention'. It lets the CPU get on with useful work and be notified exactly when a slow device finally finishes, rather than wasting cycles polling.
Here is the mechanism step by step. A device raises an interrupt line. At a safe point between instructions, the CPU notices, saves enough of its current state (at least the program counter) so it can return later, and jumps to a fixed routine called the interrupt handler (or interrupt service routine) chosen by which device interrupted. The handler does the urgent work — read the data, acknowledge the device — then executes a 'return from interrupt' that restores the saved state, and the interrupted program continues as if nothing happened. Two controls keep this orderly: masking lets software temporarily ignore (defer) interrupts during a delicate operation, and priorities decide which interrupt wins if several arrive at once, so a critical timer can pre-empt a lazy keyboard.
Interrupts are the backbone of how a responsive system shares one CPU among many devices and programs. A timer interrupt is how the operating system regains control to switch between programs; a disk-done interrupt is how a waiting program is woken. The honest trade-off versus polling is overhead and latency-of-response: taking an interrupt costs time to save and restore state, and a flood of interrupts (say, from a very fast network card) can swamp the CPU — which is why high-rate devices sometimes coalesce many events into one interrupt, or switch to polling.
The CPU starts a disk read and goes off to run other code. Ten milliseconds later the disk controller raises an interrupt; the CPU saves its place, jumps to the disk handler which copies the data and marks the request done, then returns to exactly where it was. No cycles were wasted spinning.
Save state, run the handler, restore state, resume — the interrupt round-trip that frees the CPU from waiting.
Interrupts are not free or instantaneous: each one costs the time to save/restore state and disturb caches. Under a heavy event rate, that overhead is why drivers sometimes coalesce interrupts or fall back to polling.