The Non-Preemptive Execution Flow

To visualize this philosophy, consider the lifecycle of execution. Once a process is selected from the Ready Queue, it enters the running state and remains there. The CPU cannot swap it out mid-way.

Three Classic Non-Preemptive Policies

When the kernel does not interrupt, the only choice it makes is who starts next. This choice is guided by one of three classic rules:

* First-Come, First-Served (FCFS): The simplest possible rule. Whichever process enters the Ready Queue first is run first, regardless of how long it takes or its importance. * Shortest Job First (SJF): The scheduler searches the Ready Queue and executes the process with the shortest estimated burst time first. * Priority Scheduling: Each process is tagged with an integer representing its priority. The scheduler always starts the process with the highest priority next.

Investigating Scheduling Behavior

To see how these rules change the behavior of a system, let's trace them using a single, identical set of processes.

The Key Metrics: Turnaround vs. Waiting

When evaluating these schedulers, engineers look at two primary performance metrics:

* Turnaround Time ($TAT$): The total elapsed time from when a process first arrives in the queue to when it completely finishes execution ($TAT = \text{Completion Time} - \text{Arrival Time}$). * Waiting Time ($WT$): The total time a process spends sitting in the Ready Queue waiting to execute ($WT = \text{Turnaround Time} - \text{Burst Time}$).

As you simulated above: * FCFS scheduled processes exactly in arrival sequence, resulting in an average waiting time of 4.67 units. * SJF reduced average waiting time to 3.67 units by running the shorter $P_3$ before $P_2$. * Priority prioritized the urgent $P_2$ over $P_3$, resulting in an average waiting time of 4.67 units.

The EdgeCase: Emergency Arrival

These non-preemptive rules worked well for early batch-processing computers. But what happens in a real-time system when an critical task suddenly wakes up?

Select the EdgeCase simulation tab above. In this scenario, we use the exact same process table, but we introduce one addition: at Time = 1, an emergency process ($P_{EM}$) with priority 0 (highest) arrives.

Observe the timeline: * At Time = 0, $P_1$ begins running. * At Time = 1, $P_{EM}$ arrives. It is the most critical process in the system. * But because the scheduler is non-preemptive, $P_1$ cannot be interrupted. $P_{EM}$ is forced to wait in the Ready Queue for 5 full time units until $P_1$ finishes at Time = 6.

This is the fundamental limitation of non-preemptive scheduling: long-running tasks block critical work, and the kernel is powerless to stop them.

The early policies were simple and predictable. But when a system must react to user inputs or critical hardware interrupts, waiting is no longer an option.

Should the CPU continue executing a long task, or should it force it to yield?

Let's find out how the kernel breaks the rule of non-preemption.