polling

Imagine you are baking and keep opening the oven every ten seconds to check if the cake is done. You get instant news the moment it is ready, but you cannot do anything else while you hover by the oven. Polling is the computer's version of repeatedly checking. The CPU asks a device 'are you done yet?' over and over — reading the device's status register in a tight loop — until the answer is yes. It is the simplest of the three ways to handle a device event.

Mechanically, polling is a loop that reads a status register and tests a bit: while the 'ready' bit is 0, loop and read again; when it flips to 1, proceed. There are no special hardware tricks needed beyond memory-mapped I/O, which is why polling is easy to write and easy to reason about. The catch is that every one of those status reads is the CPU spinning and doing no useful work; this is called busy-waiting. If the device takes ten milliseconds to finish, the CPU may waste millions of cycles asking 'done? done? done?'.

So when is polling the right choice, and when is it wasteful? Polling wins when the wait is very short or when you want the lowest possible latency and have a spare CPU to burn — for instance, a high-speed network or NVMe driver may poll because an interrupt's overhead would cost more than the brief spin. Polling loses when waits are long and unpredictable; then you want an interrupt so the CPU can sleep or do other work and be woken only when the device is ready. The honest summary: polling trades CPU time for simplicity and low latency; interrupts trade a little latency and complexity for not wasting the CPU.