What causes the convoy effect in FCFS scheduling?

Concept

FCFS (First-Come, First-Served) is a non-preemptive scheduling policy: once a process gets the CPU, it runs to completion (or until it voluntarily blocks for I/O) and cannot be interrupted. The convoy effect is the phenomenon where many short processes are forced to queue behind one long-running CPU-bound process, the way a line of fast cars piles up behind one slow truck. The harm is greatest for I/O-bound processes, which normally use the CPU only briefly before going off to do I/O.

Application

Trace what happens when a long CPU-bound process holds the CPU under FCFS:

1. A CPU-bound process with a very large CPU burst is scheduled first and keeps the CPU for a long time.

2. Because FCFS is non-preemptive, every process that arrived after it must wait in the Ready Queue until it finishes.

3. The short I/O-bound processes, which need the CPU only for a tiny slice before issuing I/O, are stuck waiting. Meanwhile the I/O devices sit idle because no process can reach them.

4. Result: low device utilization and a large average waiting time for the many short jobs.

Does it block only I/O-bound processes, or all of them?

Strictly, because FCFS is non-preemptive, the long CPU-bound process blocks every later-arriving process while it runs, whether that process is CPU-bound or I/O-bound. But the convoy effect is named for, and is most damaging to, the short I/O-bound processes: had they run first, each would have used the CPU briefly and then left to do I/O, keeping both the CPU and the I/O devices busy in parallel. Trapping them behind the long job wastes that overlap, so the I/O-bound processes are the defining victims of the effect.

Cross-check

A preemptive policy such as Round Robin or SRTF would slice the long process or let the short jobs jump ahead, so the convoy never forms — confirming that the cause is the long CPU-bound process combined with FCFS's non-preemptive, arrival-order rule, not priorities, locks, or I/O bursts.