polling
Polling is the act of repeatedly asking 'are you ready yet?' Imagine a child in the back seat asking 'are we there yet?' every ten seconds for the whole trip. In computing, polling means the CPU keeps reading a device's status register in a loop, checking the same flag over and over, until the device says it is done. It is the waiting strategy used by programmed I/O.
Concretely, a polling loop looks like: read the status register; if the ready bit is not set, loop back and read it again; once it is set, do the transfer. There is a small handshake protocol behind this — the controller has a busy bit it sets while working and a done/ready bit it sets when finished, and the CPU watches those bits. A single read of a status register is cheap (often just a few instructions). The cost is doing that read thousands or millions of times while a slow device crawls toward done, which is called busy-waiting: the CPU is busy, but accomplishing nothing.
Why it matters: polling is dirt simple, has very low latency for a device that responds almost instantly, and avoids the overhead of setting up interrupts — so it is genuinely the right choice for very fast devices or when you will wait only a handful of cycles. But for slow devices it wastes enormous CPU time, and it cannot easily do anything else meanwhile. That trade-off is the whole reason interrupts were invented: instead of the CPU asking again and again, the device taps the CPU on the shoulder only when it is actually ready.
while not (status_register has READY bit set): keep looping; then read data_register. If the device takes 5 milliseconds, a 3 GHz CPU may spin through this check roughly fifteen million times, doing nothing useful.
Cheap per check, ruinous when repeated millions of times for a slow device.
Polling is not always wrong: for a device that is ready in nanoseconds, polling can beat interrupts, whose setup and context-switch cost would dominate. The mistake is polling a slow device, where you burn cycles for nothing.