Home/Learn/Operating Systems/Round Robin Scheduling

Round Robin Scheduling

Beginner
CPU Scheduling

Round Robin gives each process a fixed time quantum on the CPU in a circular order, providing fair CPU sharing and good response time for interactive systems at the cost of more context switches.

Overview

Round Robin (RR) is the most widely used scheduling algorithm for time-sharing systems. Each process in the ready queue gets a fixed CPU time slice called a time quantum (or time slice). After the quantum expires, the running process is preempted and moved to the back of the ready queue. The next process in the circular queue gets the CPU. If a process finishes before the quantum expires, the CPU is given to the next process immediately. The key trade-off is quantum size: a very large quantum degenerates to FCFS; a very small quantum causes excessive context switching overhead. The rule of thumb: 80% of CPU bursts should be shorter than the time quantum. Modern Linux uses the Completely Fair Scheduler (CFS), which is conceptually a weighted Round Robin.

Round Robin Gantt Chart with Quantum = 2

Round Robin is like a teacher in class giving each student exactly 2 minutes to answer before moving to the next. Every student gets a turn — no one waits forever. This ensures good response time for all processes, which is why it is the basis of modern OS schedulers for interactive workloads.

Java — Round Robin simulation with quantum=2
// Round Robin Example with quantum = 2
// Process | Arrival | Burst
//    P1   |    0    |   5
//    P2   |    0    |   3
//    P3   |    0    |   1
//    P4   |    0    |   2
//
// Queue order at start: [P1, P2, P3, P4]
// t=0: P1 runs 2 → remaining=3, queue: [P2, P3, P4, P1]
// t=2: P2 runs 2 → remaining=1, queue: [P3, P4, P1, P2]
// t=4: P3 runs 1 → done!         queue: [P4, P1, P2]
// t=5: P4 runs 2 → done!         queue: [P1, P2]
// t=7: P1 runs 2 → remaining=1,  queue: [P2, P1]
// t=9: P2 runs 1 → done!         queue: [P1]
// t=10:P1 runs 1 → done!
//
// Gantt: |P1|P2|P3|P4|--|P1|P2|P1|
//         0  2  4  5  7  9 10  11
//
// Turnaround: P1=11, P2=10, P3=5, P4=7
// Waiting:    P1=6,  P2=7,  P3=4, P4=5
// Avg Waiting = (6+7+4+5)/4 = 5.5

int quantum = 2;
int[] burst = {5, 3, 1, 2};
int[] remaining = burst.clone();
int n = burst.length;
int[] finish = new int[n];
int time = 0;

Queue<Integer> queue = new LinkedList<>();
for (int i = 0; i < n; i++) queue.add(i);

while (!queue.isEmpty()) {
    int i = queue.poll();
    if (remaining[i] > 0) {
        int run = Math.min(remaining[i], quantum);
        System.out.printf("P%d runs t=%d to t=%d%n", i+1, time, time + run);
        time += run;
        remaining[i] -= run;
        if (remaining[i] > 0) queue.add(i);
        else finish[i] = time;
    }
}
// Print results
for (int i = 0; i < n; i++)
    System.out.printf("P%d finish=%d, turnaround=%d%n", i+1, finish[i], finish[i] - 0);

Choosing the Optimal Time Quantum

Quantum size directly controls the responsiveness vs overhead trade-off. Too small (e.g., 1ms): constant context switches, CPU spends most time switching rather than working. Too large (e.g., 1000ms): degenerates to FCFS. The OS rule of thumb: choose quantum so that 80% of CPU bursts finish within one quantum — typical range is 10–100ms in modern OSes.

Java — context switch count vs quantum size trade-off
// Demonstrating quantum size impact on context switches
// Smaller quantum = better response time but more context switches

// Formula: if avg burst = B and quantum = q
// If q >= B: most processes finish in one quantum → behaves like FCFS
// If q << B: each process gets many tiny slices → high context switch overhead

// Simulating context switch count for different quantum sizes
int[] burstTimes = {12, 4, 8, 6, 10}; // ms
int[] quantums = {1, 2, 4, 8, 20};

for (int q : quantums) {
    int switches = 0;
    int[] rem = burstTimes.clone();
    boolean anyLeft = true;
    while (anyLeft) {
        anyLeft = false;
        for (int i = 0; i < rem.length; i++) {
            if (rem[i] > 0) {
                anyLeft = true;
                switches++;   // each time slice = 1 context switch
                rem[i] = Math.max(0, rem[i] - q);
            }
        }
    }
    System.out.printf("Quantum=%2d ms → Context switches: %d%n", q, switches);
}
// quantum=1:  many switches (expensive)
// quantum=20: few switches (but poor response time for short jobs)

Key Points to Remember

  • 1Round Robin gives each process a fixed time quantum in circular order — fairness by design.
  • 2If a process does not finish within its quantum, it is preempted and moved to the rear of the ready queue.
  • 3Very small quantum: excessive context switch overhead. Very large quantum: degenerates to FCFS.
  • 4Rule of thumb: choose quantum such that 80% of CPU bursts are shorter than the quantum.
  • 5Round Robin has no starvation — every process gets CPU time within at most (n-1)*quantum wait.
  • 6Linux CFS is a weighted Round Robin with dynamic time slices based on process priority (nice value).

Interview Questions

Sign in to ask Aria
1

What happens to Round Robin scheduling when the time quantum is very large?

EasyAmazon
2

Calculate average waiting and turnaround time for 4 processes with Round Robin quantum=2.

MediumMicrosoft
3

What is the rule of thumb for choosing an optimal time quantum?

MediumGoogle
4

How does Linux CFS differ from classic Round Robin?

HardNetflix

Ask Aria about Round Robin Scheduling

Your personal AI tutor — ask anything about this concept

Revision Status

Personal Notes

Sign in to save personal notes for this topic.

Discussion

Sign in to join the discussion.

Loading discussion…