Base CS from zero
Why async exists
You know from Unit 03 that the CPU runs a fetch–decode–execute cycle, and that it does so fast — one instruction in roughly a billionth of a second. That is the speed at which arithmetic, comparisons, and jumps happen inside the processor.
But a program does more than arithmetic. It reads a file from a disk. It asks another computer across the network for some data. These are not instructions the CPU executes itself — they are requests sent to slow hardware that lives outside the CPU. And slow here does not mean “a little slower.” It means millions of times slower.
So the program has a problem. It has asked a disk for a file, and the answer will not arrive for a long time. What should the CPU do in the meantime? This lesson answers that question — and the answer is the reason a whole family of techniques, called async, exists at all.
After this lesson you can state how long a CPU instruction takes compared to a disk or network request, explain what “the CPU sits idle” means and why that is wasteful, define async as the idea that the CPU does other useful work while a slow device answers, and contrast it with the synchronous alternative of just waiting.
The CPU is fast: a cycle is about a nanosecond. Recall the fetch–decode–execute cycle from Unit 03. A modern CPU runs that cycle billions of times per second. A useful round number: one instruction takes roughly one nanosecond — one billionth of a second.
A nanosecond is too small to picture directly, so use a scale. If one CPU cycle were stretched to take one second, then the CPU runs a billion “seconds” of work in every real second. At that imagined scale, the CPU is doing one step per second, steadily, without pause. This is the rate at which a program’s arithmetic, variable assignments, and jumps all happen.
A slow device is millions of cycles away. A device is a piece of hardware outside the CPU: a disk that stores files, or a network card that sends and receives data over a cable. When a program needs a file or a reply from another computer, the CPU sends a request to one of these devices and the device takes time to answer.
How much time? A hard disk takes about ten milliseconds to find and return data. A network request to another computer can take tens or hundreds of milliseconds. A millisecond is a thousandth of a second — and the CPU runs about one million cycles in a single millisecond.
So a ten-millisecond disk read is roughly ten million CPU cycles long. Using the scale from Step 1 — one cycle stretched to one second — ten million cycles is about four months. The CPU asked the disk a question and the answer takes, in CPU terms, a third of a year.
Sitting idle: the waste. Here is the naive thing a program could do after sending a request to a slow device: nothing. It tells the CPU to stop and wait for the device to answer before running the next instruction. This is called sitting idle — the CPU is powered on, but it is not doing useful work; it is just waiting.
Think about what that costs. During a ten-millisecond disk read, the CPU could have run ten million instructions. If it sits idle instead, those ten million instruction-slots are gone — spent on nothing. The hardware is capable of enormous work and is being used for none of it.
For one disk read this is wasteful. For a program that does thousands of disk and network requests — a web server answering many users, say — sitting idle each time would make the machine almost entirely useless. The CPU would spend nearly all its time waiting and almost none of it computing.
Why this works
Why is the device so slow — is it broken? No. The CPU is fast because it works with electrical signals inside a tiny chip, over distances measured in nanometres. A disk has to physically move a read head and wait for a spinning platter; a network request has to travel down a cable, possibly across a country, and come back. These involve real physical motion or real distance. Physics, not a defect, sets the floor. The device cannot be made as fast as the CPU, so the program must be arranged to cope with the gap.
Async: do other useful work while you wait. The way out is to not sit idle. When a program sends a request to a slow device, it does not have to stop. It can let the CPU go on and run other instructions — work that does not depend on the device’s answer — and come back to handle the answer once it has actually arrived.
This idea is called async, short for asynchronous. The word means “not in step”: the request and its answer are not locked together in time. The program fires off the request, keeps the CPU busy with other work, and the device’s answer is dealt with later, whenever it shows up.
The opposite approach — fire the request, then stop and wait for the answer before doing anything else — is called synchronous: the program and the device move in lockstep. Synchronous is simpler to think about, but it is exactly the “sit idle” behaviour from Step 3. Async exists precisely to avoid that waste: it keeps the fast CPU busy across the huge time gap that a slow device opens up.
Counting the wasted cycles.
A program does one disk read that takes 10 milliseconds. The CPU runs at one cycle per nanosecond — so it can run 1,000,000 cycles per millisecond.
Synchronous version. The program asks the disk, then sits idle until the answer comes.
- Idle time: 10 milliseconds.
- Cycles available during that time: 10 ms × 1,000,000 = 10,000,000 cycles.
- Useful instructions run during the wait: 0.
- Wasted instruction-slots: 10,000,000.
Async version. The program asks the disk, then keeps the CPU running other work that does not need the file — updating a counter, preparing the next request, serving a different user.
- Idle time: still 10 milliseconds of device time.
- But the CPU is not idle: it spends those 10 million cycles on other instructions.
- Wasted instruction-slots: 0.
The disk takes 10 milliseconds either way — async does not speed the disk up. What async changes is whether the CPU is wasted during those 10 milliseconds. Synchronous throws away ten million cycles; async keeps every one of them working.
Common mistake
A common misconception is that async makes the slow device faster. It does not. The disk still takes its 10 milliseconds; the network request still takes its hundreds of milliseconds. Async changes nothing about the device. It only changes what the CPU does during the wait — idle (wasted) or busy with other work (async). The total time for the device’s own answer is unchanged.
A CPU runs roughly one instruction per nanosecond. How many instructions can it run in one millisecond (one thousandth of a second)?
A disk read takes 10 milliseconds. The CPU runs 1,000,000 cycles per millisecond. If the CPU sits idle for the whole read, how many cycles are wasted?
The same 10-millisecond disk read, but the program uses async and keeps the CPU running other work. How many cycles are wasted now?
A program sends a request to a slow device, then runs no other instructions until the answer arrives. Type 1 if this is the synchronous approach, 2 if it is async.
Async makes a 10-millisecond disk read finish in how many milliseconds of device time?
Why does async exist?
A CPU runs roughly one instruction per nanosecond, but a slow device — a disk, a network card — takes milliseconds to answer, which is millions of CPU cycles. If the program tells the CPU to stop and wait for the device, the CPU sits idle: powered on but doing no useful work, throwing away every cycle of the wait. That waiting approach is called synchronous. Async (asynchronous) is the alternative: the program sends the request, lets the CPU run other useful work that does not depend on the answer, and deals with the answer later, once it arrives. Async does not make the device faster — the disk still takes its time — it makes sure the fast CPU is never wasted while the slow device works. The rest of this unit shows how that is actually arranged.