AlgoMaster Logo

Round Robin

34 min readUpdated August 7, 2026
Listen to this chapter
Unlock Audio

On a single-CPU system, several programs may be ready to run at the same time. Imagine a text editor and shell competing for CPU time with a background compiler.

Running them strictly in arrival order is simple, but it can make the system feel unresponsive. If the compiler gets the CPU first and runs for a long time, the editor and shell may appear frozen. Running the shortest burst first could help, but the operating system cannot reliably predict how long future CPU bursts will be.

Round Robin (RR) avoids that prediction. It gives each runnable process a limited turn on the CPU. When that turn ends, any unfinished process moves to the back of the ready queue.

This limited turn is called a time quantum, or time slice. By cycling through the ready queue, Round Robin gives every runnable process regular opportunities to make progress.

The Core Idea

Round Robin uses a FIFO ready queue, much like First-Come, First-Served scheduling. The difference is preemption.

When a process reaches the front of the queue, it may run for at most one quantum:

  • If it completes or blocks before the quantum ends, it gives up the CPU early.
  • If it is still runnable when the quantum expires, the kernel preempts it and appends it to the back of the queue.
  • The process now at the front receives the CPU.

Requeueing at the back is what makes this Round Robin rather than FCFS. A process that is still runnable when its quantum expires does not keep the CPU, and it does not jump ahead of anyone either.

Newly runnable processes also join the back of the queue. A process that blocks is removed from the runnable population; when its event occurs, it becomes runnable and joins the queue again.

Round Robin is therefore:

  • Preemptive, because the kernel can interrupt a still-runnable process
  • Time-sharing, because runnable processes take turns
  • Length-oblivious, because it does not need future CPU-burst estimates

What the Quantum Controls

Let the quantum be q.

If a process needs no more than q units of CPU time, it can finish its burst during one turn. If it needs more, it executes for q units, is preempted, and keeps its remaining work for a later turn.

Suppose q = 3 and process P needs eight CPU units:

A fresh quantum is available each time P is dispatched. Unused time does not accumulate as credit. If P blocks after one unit of a three-unit quantum, it does not receive a five-unit quantum when it wakes.

The quantum limits one continuous turn, not the process's total CPU usage. A long-running process may receive thousands of quanta over its lifetime.

A Queue Rotation

Assume three CPU-bound processes are ready and q = 2:

A runs for two units and remains unfinished:

B then receives a turn:

After C's turn:

The queue has completed one rotation. If every process remains runnable and uses its full quantum, each receives two CPU units per rotation.

This regular rotation is the central Round Robin mental model.

Events During a Quantum

A process's turn can end in several ways.

The process finishes

It leaves the system and is not requeued:

With q = 4 and P needing only 2 units, P runs from time 0 to time 2 and completes.

The CPU immediately moves to the next ready process. It does not remain reserved for P until time 4.

The process blocks

Suppose P performs one unit of computation and then waits for network data:

The next ready process can run immediately. When the network event occurs, P becomes runnable and joins the back of the queue.

The quantum expires

If P is still runnable after q units, the timer gives the kernel control. P is preempted and requeued with a reduced remaining time.

No other process is ready

If P's quantum expires but P is the only runnable process, selecting it again is reasonable. The kernel may renew its turn without switching to a different task.

Quantum expiration creates a scheduling decision; it does not guarantee a context switch.

Arrival and Requeue Order

Scheduling calculations need a rule for events that occur at the same timestamp.

Suppose process N arrives exactly when process A's quantum expires. Two orders are possible:

The choice can change individual response times.

For this chapter, we use the following convention:

Processes arriving at a boundary enter the ready queue before the process whose quantum expires at that boundary is requeued.

Other conventions are valid if stated explicitly and applied consistently. A real implementation defines a precise ordering through its event-handling and queueing rules.

A Complete Worked Example

Use the following processes:

ProcessArrival timeCPU burst time
P108
P214
P322
P431

Assume:

  • One CPU
  • Quantum q = 3
  • No blocking
  • Zero context-switch cost
  • Boundary arrivals are enqueued before an expired process is requeued

The total required CPU time is:

Building the Timeline

Time 0 to 3: P1

At time 0, only P1 has arrived:

P1 runs for one full quantum:

While P1 runs, P2 arrives at time 1 and P3 at time 2. P4 arrives at the time-3 boundary. Applying our boundary rule, P4 enters before P1 is requeued:

Time 3 to 6: P2

P2 runs for three units:

P2 is unfinished, so it moves to the back:

Time 6 to 8: P3

P3 needs only two units. It completes before using the full quantum:

The unused one unit is not transferred to another process as a larger quantum. P4 simply starts at time 8 with its normal quantum.

Time 8 to 9: P4

P4 completes its one-unit burst:

Time 9 to 12: P1

P1 receives its second turn:

Time 12 to 13: P2

P2 needs one more unit and completes:

Time 13 to 15: P1

P1 is the only remaining process. It executes its final two units and completes at time 15.

The complete schedule is:

Verify each process's CPU service:

Every total matches the original burst time.

Response, Waiting, and Turnaround

P1 arrives and starts at time 0:

Its waiting intervals are time 3 to 9 and time 12 to 13:

P2 arrives at time 1, first runs at time 3, and completes at 13:

P2 waits two units before its first turn and six units between its turns.

P3 arrives at time 2 and runs from time 6 to 8:

P4 arrives at time 3 and runs from time 8 to 9:

The averages are:

Response and waiting time differ because P1 and P2 wait again after their first execution. Response measures only the delay until the first turn; waiting includes all ready-queue delay.

Why Quantum Size Matters

Round Robin's behavior depends strongly on q.

A very large quantum lets each process run for a long time before preemption. If the quantum is at least as large as every CPU burst, no process is preempted and Round Robin behaves like FCFS.

A smaller quantum lets the scheduler rotate through the ready queue more frequently. Processes near the back receive their first turn sooner, which can improve response time.

With the large quantum, P3 does not appear at all in the interval shown. With the small one, every process has had a turn by the halfway point.

But making the quantum smaller increases the number of preemptions and potential context switches. Time spent switching is not application work, and more frequent task changes can disrupt cache locality.

The quantum therefore balances:

  • Prompt turns for runnable work
  • The overhead and locality cost of frequent switching

There is no universal best value. It depends on switching cost, workload burst lengths, latency goals, and the system's broader scheduling policy.

Comparing Several Quantum Sizes

Using the same four-process workload, consider three quantum choices. The q = 1 calculation uses the same boundary-arrival rule as the worked example. A quantum of at least 8 lets every process finish its burst in one turn, making the schedule equivalent to FCFS.

QuantumAverage responseAverage waitingAverage turnaroundTask-to-task switches
10.754.758.5011
32.756.009.756
At least 87.007.0010.753

With zero switching cost, the smaller quantum improves all three averages for this particular workload because later short processes begin earlier.

The number of task-to-task switches moves in the opposite direction. With real switching cost, the q = 1 schedule would extend beyond time 15 and its completion metrics would increase.

This table does not establish that q = 1 is always best. Different arrival patterns and burst lengths can produce different results, and real overhead makes extremely small quanta unattractive.

Loading simulation...

The q = 1 Timeline

The shorter-quantum result can be verified from its execution order:

Time01234567891011 to 15
CPUP1P2P1P3P2P4P1P3P2P1P2P1

P1 is the only remaining process after time 11, so its final four units are shown as one continuous interval. Quantum boundaries may still create scheduling decisions, but reselecting P1 does not switch the CPU to a different process.

Completion times are:

The metrics are:

These values produce the averages in the comparison table.

Quantifying Switching Overhead

Let:

  • q be the quantum
  • s be the time required to switch from one runnable process to another

If every process uses a full quantum and every expiration switches to a different process, one repeating interval consists of:

The fraction spent switching is approximately:

If q = 1 ms and s = 0.1 ms:

If q = 10 ms with the same switch cost:

This is a simplified upper-pressure model, not a universal measurement. Processes may block early, the same process may be selected again, and indirect cache effects are not included in s.

The calculation still illustrates an important design constraint: the quantum should be meaningfully larger than the cost of switching, or overhead can consume a significant share of CPU capacity.

Response Bounds in the Simplified Model

Suppose n processes remain continuously runnable, every process uses its complete quantum, and switching is free.

One full queue rotation takes:

After a process finishes its turn, it waits while the other n - 1 processes run:

For four runnable processes and q = 3:

If a new process joins the back behind n existing processes, its first response can take up to approximately:

Switching overhead adds delay. Processes that finish or block early shorten the rotation, while newly runnable work changes the queue length.

These bounds are useful mental models, but they apply only to the stated FIFO, equal-quantum assumptions. CPU affinity, priorities, throttling, and other constraints can change real scheduling delay.

Fairness and Progress

In basic Round Robin, every process that remains runnable returns to the back of the queue after its turn. New arrivals also join the back rather than jumping ahead.

With a finite runnable population and a positive quantum, each queued process eventually reaches the front. Basic Round Robin therefore avoids the starvation caused by continually selecting shorter jobs.

If n CPU-bound processes remain runnable for a long period, each receives approximately:

ignoring switching overhead.

This is equal-turn fairness, not necessarily the right fairness model for every system. Some workloads may need different CPU shares or stronger urgency guarantees. Basic Round Robin gives every runnable process the same maximum turn without considering job length or importance.

Equal turns also do not mean equal observed CPU usage. A process that blocks after a small amount of computation uses less than its quantum. Round Robin does not force it to burn the unused time.

CPU-Bound and I/O-Bound Behavior

CPU-bound processes often use their entire quantum and return to the ready queue:

An I/O-bound process may run briefly and block before its quantum expires:

An I/O-bound process Q runs for half a unit, requests I/O, and blocks. It wakes later and rejoins the queue.

Q's early block allows the next process to start immediately. It does not make the CPU idle while runnable work exists.

When Q wakes, it receives a position at the back of the ready queue. Round Robin does not automatically place it at the front merely because its previous burst was short.

This behavior gives both kinds of work recurring access to the CPU without requiring the scheduler to predict their next burst lengths.

Idle Intervals

Round Robin cannot rotate through an empty queue.

Suppose P1 arrives at time 0 with a two-unit burst, P2 arrives at time 5 with a one-unit burst, and q = 3:

Time rangeCPU
0 to 2Running P1
2 to 5Idle
5 to 6Running P2

P1 finishes before using its full quantum. With no runnable process available, the CPU is idle from time 2 through time 5. The scheduler must advance to P2's arrival rather than repeatedly drawing empty quantum intervals.

The quantum limits runnable execution; it does not manufacture work.

Round Robin Pseudocode

A simplified event-driven version looks like this:

A calculation or simulator must also process arrivals that occur while the current process runs. Those processes enter the queue immediately at their arrival times, even though they do not preempt the current turn under basic Round Robin.

A Reliable Calculation Method

Record every process's arrival time and remaining burst time. Keep an explicit FIFO queue rather than trying to infer the order from the final timeline.

At each dispatch:

Move time forward by that execution length. Before requeueing the current process, add every process that arrived during the interval, applying the declared boundary rule.

Then:

  • Remove the current process if it finished.
  • Remove it from the runnable population if it blocked.
  • Otherwise, append it to the back because its quantum expired.

Repeat until every process completes.

After constructing the timeline, calculate metrics from first start and final completion:

The waiting-time shortcut assumes the single-burst, no-blocking model. For a process with I/O waits, sum ready-queue intervals or subtract blocked time as well.

Finally, verify that the execution intervals for each process add to its original burst time. This check catches missed or duplicated quanta.

Choosing a Quantum in Practice

A useful quantum must be considered relative to the workload, not as an isolated number.

If most CPU bursts finish well before q, many processes voluntarily give up the CPU and changing the quantum may have little effect.

If many runnable processes use the entire quantum, reducing q shortens the queue rotation and can improve initial response. It also increases scheduling frequency and task switching.

If q is much larger than typical bursts, Round Robin rarely preempts. The system behaves increasingly like FCFS for those bursts.

Practical evaluation should observe:

  • Response and completion latency, including the tail
  • Number of runnable tasks
  • Voluntary and involuntary context-switch rates
  • CPU time lost to direct and indirect switching costs
  • Throughput under representative load

The goal is not to maximize the number of turns. It is to provide sufficiently prompt service without letting scheduling overhead dominate useful execution.

Round Robin Outside CPU Scheduling

The phrase round robin is also used for application-level distribution.

A load balancer might send request 1 to server A, request 2 to B, request 3 to C, and request 4 back to A:

This resembles queue rotation, but it is not CPU Round Robin. The load balancer normally assigns each request once; it does not interrupt a long request after a quantum and move its partially executed state to another server.

As a result, application-level round-robin routing can still create imbalance when request costs differ. One server may receive several expensive requests while another receives cheap ones.

The shared idea is cyclic selection. CPU Round Robin adds preemption, saved execution state, and repeated turns for unfinished work.

Round Robin and Real Operating Systems

Classical Round Robin is a clean model: one FIFO queue, one quantum, and equal treatment of every runnable process.

A modern general-purpose operating system must account for additional concerns such as different task importance, multiple CPUs, hardware locality, and groups of related tasks. Its ordinary scheduling behavior should not be assumed to be this exact single-queue algorithm merely because processes appear to take turns.

The classical model remains valuable because it isolates the effect of bounded, rotating CPU turns. It explains why preemption improves responsiveness, why quantum size matters, and why switching overhead cannot be ignored.

Summary

Round Robin gives each runnable process at most one time quantum, then requeues unfinished work at the back of a FIFO ready queue. Processes that finish or block give up the CPU early, and unused quantum does not carry forward.

A smaller quantum rotates through runnable work sooner and often improves initial response, but it increases preemption, context-switch overhead, and locality disruption. A very large quantum makes Round Robin approach FCFS.

Under its basic equal-quantum assumptions, Round Robin provides recurring progress without predicting burst lengths and avoids starvation for a finite runnable population. Correct calculations require explicit queue tracking, remaining-time updates, and a consistent rule for arrivals at quantum boundaries.

Quiz

Round Robin Quiz

5 quizzes