the convoy effect
Picture a single-lane road behind one slow truck: a line of fast cars piles up unable to pass, all forced to crawl at the truck's pace. The convoy effect in scheduling is exactly this — under first-come, first-served, one long CPU-bound process at the front of the queue holds the CPU while many short processes bunch up behind it, all stuck waiting for the slowpoke to finish.
Here is the mechanism that makes it worse than it sounds. Suppose one big computation and several quick I/O-bound jobs share the CPU under FCFS. The big job grabs the CPU and runs for a long time. The little jobs wait, then each gets a tiny CPU burst and quickly goes off to do I/O. Meanwhile the big job, having returned from its own I/O, may again get ahead of them, and the pattern repeats: the small jobs keep clustering behind the big one. Both CPU and I/O devices end up underused, because everyone is synchronized to the slow process.
Why it matters: the convoy effect is the headline argument against plain FCFS, and the motivation for preemption and for favoring short jobs. Round-robin breaks it by forcing the long job to yield after a quantum; shortest-job-first avoids it by not letting the long job go first. Recognizing the pattern — short tasks throttled by one long one holding a shared resource — also shows up beyond CPU scheduling, for instance with a slow lock-holder in concurrent code.
One CPU-bound job of 100 ms is at the head; ten I/O-bound jobs each needing 1 ms of CPU are behind it. Under FCFS each short job waits roughly 100 ms before its 1 ms turn — they are convoyed behind the giant. Switch to round-robin with a 10 ms quantum and each short job runs within the first few quanta instead.
One long job at the head of a FIFO queue drags everyone behind it down to its pace.
The convoy effect is not caused by the long job being long — it is caused by FCFS running it to completion without preemption. Add preemption (round-robin) and the convoy dissolves.