the CPU-I/O burst cycle

Watch what a typical program really does over time and you will see it alternate between two phases, like a writer who thinks for a while (working on paper) and then walks to the library to fetch a book (waiting). The thinking phase is a CPU burst — the program is computing and needs the processor. The library trip is an I/O burst — the program has asked to read a file, wait for the network, or print something, and during that time it does not need the CPU at all.

Concretely: a process runs, does some arithmetic and comparisons (a CPU burst), then issues a request like read(fd, buf, n). Reading from a disk or network is enormously slow compared to the CPU — millions of CPU cycles can pass while one disk read completes. Rather than waste those cycles spinning, the OS marks the process as waiting and gives the CPU to another ready process. When the I/O finishes, an interrupt wakes the first process and it eventually gets another CPU burst. The whole life of a process is this cycle repeating: CPU burst, I/O burst, CPU burst, I/O burst, until it exits.

This pattern is the entire reason scheduling pays off. Programs split into two kinds: CPU-bound jobs have long CPU bursts and rare I/O (think rendering a video), while I/O-bound jobs have short CPU bursts and constant waiting (think a text editor). Good schedulers exploit the gaps — when an I/O-bound process steps away to wait, a CPU-bound process can use the idle CPU, so the machine gets more done. Measured burst lengths also tend to follow a curve with many short bursts and few long ones, which several algorithms quietly rely on.