Round Robin Scheduling
- Process Management
- Memory Management
- Deadlocks
- OS Introduction & Fundamentals
- CPU Scheduling Algorithms
- Threads & Concurrency
- Inter-Process Communication (IPC)
- Process Synchronization
- Virtual Memory & Paging
- File Systems
- Disk Scheduling
- I/O Management
Every Process Gets a Fixed Turn, No Exceptions
Round Robin assigns each process a small, fixed unit of CPU time (a "time quantum"), then moves on to the next process in a rotating queue - and comes back around to the same process again later, if it still isn't finished.
A Worked Example With a Time Quantum of 4
Process Burst Time
P1 8
P2 4
P3 9
Time quantum = 4
Timeline:
|-P1(0-4)-|-P2(4-8)-|-P3(8-12)-|-P1(12-16)-|-P3(16-21)-|
(P2 finished after its first 4 units; P1 and P3 needed extra turns)Why the Time Quantum's Size Is the Whole Design Question
The time quantum's length determines nearly everything about how Round Robin actually behaves - too large or too small, and its benefits disappear in opposite ways.
| Quantum size | Effect |
|---|---|
| Too large | Behaves almost exactly like FCFS - a process may finish entirely within its first turn |
| Too small | Excessive context-switch overhead (covered earlier) dominates, wasting real CPU time |
| Well-tuned | Good responsiveness with acceptable overhead - the actual goal |
Why Round Robin Feels Responsive for Interactive Use
Because every process is guaranteed to get the CPU again within a bounded amount of time, no single process can indefinitely block others from making progress - exactly the property that makes Round Robin a natural fit for interactive, time-sharing systems (covered in the OS types note earlier in this section), where responsiveness genuinely matters.
The Trade-off: Fairness Over Raw Efficiency
Round Robin doesn't optimize for the lowest possible average waiting time the way SJF does (covered in the previous note) - it optimizes for fairness and responsiveness instead, a deliberately different goal, suited to a genuinely different kind of workload.