Process Scheduling — OS Concepts

Hand the same three processes to two different schedulers and they can finish in a completely different order, with completely different average waiting times. That one fact is the whole point of process scheduling: the workload does not change, but the rule for serving it does, and that rule decides who runs now and who waits.

Process scheduling is the operating system decision about which ready process gets the CPU next. In the usual model, processes move between states such as ready, running, and waiting, and the scheduler chooses among the ready ones. It does not create new work — it decides the order in which waiting work gets CPU service. (Modern kernels often schedule threads directly, but "process scheduling" remains the standard teaching term.)

The Algorithms Side by Side

A non-preemptive scheduler lets a running process keep the CPU until it finishes its burst or blocks; FCFS is the standard example. A preemptive scheduler can interrupt a running process and hand the CPU to another; round robin and many priority schemes do this. That distinction matters because response time often improves when the system is allowed to preempt long-running work.

What the Scheduler Is Balancing

A scheduler usually juggles low waiting time, quick response for interactive tasks, good throughput, fairness, and predictability. These goals conflict. A policy that lowers average waiting time in a simplified example may still feel unfair in practice, and a fair time-sharing policy may delay a short job's completion.

When to Use Which

If you care most about quick first responses, prefer frequent sharing such as round robin. If you care most about finishing many short jobs quickly, prefer a policy that favors short bursts such as SJF. If you care about strict timing guarantees, you need a scheduler designed for deadlines. Think of process scheduling as queue discipline for the CPU: the ready queue holds the same jobs, but the serving rule changes what users experience.

Worked Comparison: FCFS vs SJF

Three processes all arrive at time $0$, each needing only CPU time:

• $P_1$: $6\ \mathrm{ms}$
• $P_2$: $2\ \mathrm{ms}$
• $P_3$: $1\ \mathrm{ms}$

Assume one CPU, no I/O blocking, and ignored context-switch cost. Waiting time is time spent in the ready queue before running, and

FCFS, order $P_1 \rightarrow P_2 \rightarrow P_3$:

Waiting times $P_1 = 0$, $P_2 = 6$, $P_3 = 8$, so

SJF (non-preemptive), order $P_3 \rightarrow P_2 \rightarrow P_1$:

Waiting times $P_3 = 0$, $P_2 = 1$, $P_1 = 3$, so

The workload never changed, but the rule did. SJF gives lower average waiting time here because the short jobs are not stuck behind the long one — though that does not make SJF the best real-world choice, only the better one under these assumptions.

To see why "best" depends on the goal, run the same three processes under round robin with a quantum of $2\ \mathrm{ms}$. The ready queue is served in slices, cycling $P_1, P_2, P_3$ and back:

$P_2$ finishes at $4$ and $P_3$ at $5$, so both short jobs see a response far sooner than they did under FCFS, where $P_3$ waited until time $8$ just to start. Round robin does not beat SJF on average waiting time here, but it gives the interactive-feeling tasks quick early service. That is the whole tradeoff in miniature: the same jobs, three rules, three different notions of "good."

When to Reach for Each Rule

Match the policy to what the workload values. A batch system that mostly runs predictable, long computations can accept FCFS because simplicity and order matter more than snappiness. A system dominated by many short, known-length jobs leans toward SJF to cut average waiting time. An interactive desktop or shared server leans toward round robin so no single long job freezes everyone else. A system where some tasks genuinely outrank others — a control loop next to background logging — leans toward priority scheduling, with a guard against starving the low-priority work. The mistake is assuming one of these is correct everywhere; the right answer is whichever protects the metric you actually care about.

Frequent Confusions on Scheduling Problems

• No policy is universally best. A rule can look excellent on average waiting time and still be poor for fairness or deadlines.
• Waiting, response, and turnaround time differ. Response time usually means time until first CPU service or first visible response; turnaround time measures the whole job from arrival to completion.
• The formula's assumptions matter. Add I/O blocking, different arrival times, or context-switch overhead and the timeline changes.
• Preemption changes the answer. SJF and shortest-remaining-time-first are not the same rule, and priority scheduling behaves differently depending on whether a higher-priority job can interrupt the current one.

Process scheduling shows up wherever an OS shares CPU time: responsive desktop and mobile apps, servers handling many requests, batch systems chasing throughput, and real-time systems needing timing guarantees. Real schedulers are more complex than textbook versions, but the same tradeoffs recur — which is why the first move on any scheduling question is to ask what the workload values most, then pick the policy that protects it.