Process Scheduling — OS Concepts

Process scheduling is the operating system decision about which ready process gets the CPU next. In plain language, it is the rule for choosing who runs now and who waits. That rule changes waiting time, response time, fairness, and overall throughput.

Process scheduling matters because the same set of processes can finish in a very different order under FCFS, SJF, or round robin. If you understand that one idea, most textbook examples become much easier to read.

What Process Scheduling Means In OS

In the usual OS model, processes move between states such as ready, running, and waiting. The scheduler chooses among the ready processes.

That is why process scheduling is often called CPU scheduling. It does not create new work. It decides the order in which waiting work gets CPU service.

In modern systems, the kernel often schedules threads directly, but the classic term "process scheduling" is still the standard teaching term.

What A Scheduler Is Trying To Optimize

A scheduler is usually trying to balance several goals:

• low waiting time
• quick response for interactive tasks
• good throughput
• fairness
• predictable behavior

These goals can conflict. A policy that lowers average waiting time in one simplified example may still feel unfair in practice, and a fair time-sharing policy may delay the completion of a short job.

Preemptive vs Non-Preemptive Scheduling

A non-preemptive scheduler lets a running process keep the CPU until it finishes its CPU burst or blocks. First-come, first-served is the standard example.

A preemptive scheduler can interrupt a running process and give the CPU to another one. Round robin and many priority schedulers do this.

That distinction matters because response time often improves when the system is allowed to preempt long-running work.

Common Process Scheduling Algorithms

First-Come, First-Served

First-come, first-served, or FCFS, runs processes in arrival order. It is easy to understand and simple to implement, but a long job at the front can make every short job behind it wait.

Shortest Job First

Shortest job first, or SJF, prefers the process with the smallest CPU burst. In a simplified setting where burst lengths are known accurately, it can reduce average waiting time. In real systems, that burst length usually has to be estimated.

Round Robin

Round robin gives each ready process a small time slice called a quantum. If the process does not finish in that slice, it goes back to the ready queue. This usually improves fairness and responsiveness for interactive workloads.

Priority Scheduling

Priority scheduling runs the highest-priority ready process first. It can be useful when some tasks matter more than others, but if low-priority tasks wait too long, starvation becomes a risk.

One Worked Example With Waiting Time

Suppose three processes all arrive at time $0$ and each needs only CPU time:

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

Assume:

• there is one CPU
• there is no I/O blocking
• context-switch cost is ignored

Under those conditions, waiting time means time spent in the ready queue before a process runs. Turnaround time is

$$\text{turnaround time} = \text{completion time} - \text{arrival time}$$

FCFS

If FCFS is used, the order is $P_1 \rightarrow P_2 \rightarrow P_3$.

Timeline:

$$0 \to 6: P_1,\qquad 6 \to 8: P_2,\qquad 8 \to 9: P_3$$

Waiting times:

• $P_1 = 0$
• $P_2 = 6$
• $P_3 = 8$

Average waiting time:

$$\frac{0 + 6 + 8}{3} = \frac{14}{3}\ \mathrm{ms}$$

SJF

If non-preemptive SJF is used, the order is $P_3 \rightarrow P_2 \rightarrow P_1$.

Timeline:

$$0 \to 1: P_3,\qquad 1 \to 3: P_2,\qquad 3 \to 9: P_1$$

Waiting times:

• $P_3 = 0$
• $P_2 = 1$
• $P_1 = 3$

Average waiting time:

$$\frac{0 + 1 + 3}{3} = \frac{4}{3}\ \mathrm{ms}$$

This example shows the main intuition. The workload did not change, but the rule changed the result. Here, SJF gives a lower average waiting time because the short jobs are not stuck behind the long one.

That does not mean SJF is always the best real-world choice. It means that under this example's assumptions, the scheduling order matters a lot.

The Intuition To Remember

Think of process scheduling as queue discipline for the CPU. The ready queue may contain the same jobs, but the rule for serving that queue changes what users experience.

If you care most about quick first responses, you may prefer frequent sharing. If you care most about finishing many short jobs quickly, you may prefer a policy that favors short bursts. If you care about strict timing, you may need a different scheduler again.

Common Mistakes In Scheduling Problems

Assuming one policy is universally best

There is no single winner for every workload. A policy can look excellent on average waiting time and still be poor for fairness or deadlines.

Mixing up waiting time, response time, and turnaround time

These metrics are related but not identical. In particular, response time usually means time until first CPU service or first visible response, while turnaround time measures the whole job from arrival to completion.

Ignoring the condition behind the formula

Metrics are only meaningful under stated assumptions. If a problem includes I/O blocking, different arrival times, or context-switch overhead, the timeline and results change.

Forgetting whether the policy is preemptive

SJF and shortest remaining time first are not the same rule. Priority scheduling also behaves differently depending on whether a higher-priority job can interrupt the current one.

Where Process Scheduling Is Used

Process scheduling matters anywhere an operating system has to share CPU time:

• desktop and mobile systems that need responsive apps
• servers that handle many requests
• batch systems that care about throughput
• real-time systems that care about timing guarantees

Real schedulers are usually more complex than textbook versions, but the same tradeoffs still show up.

Try Your Own Version

Change the example so that $P_2$ arrives later, or replace FCFS with round robin using a $2\ \mathrm{ms}$ quantum, and see how the waiting pattern changes. If you want one more step after doing it by hand, try your own version in GPAI Solver and compare your predicted timeline with the computed one.