CPU scheduling is like being a traffic controller for your computer's brain. When multiple programs want to run at the same time, the operating system needs to decide which one gets to use the CPU and for how long. This decision can make the difference between a snappy, responsive system and a sluggish one.
This interactive guide lets you experiment with five different scheduling strategies. Use the sidebar to create your own processes, adjust their timing, and watch how each algorithm handles them. You'll see exactly why some algorithms work better for certain situations than others.
💡Pro Tip: Try creating processes with very different burst times (like 1ms and 10ms) to see how dramatically the algorithms behave differently!
First-Come-First-Served (FCFS)
🧩 What is FCFS?
First-Come-First-Served is exactly what it sounds like - imagine a single checkout line at a grocery store. The first person in line gets served first, then the second, and so on. No cutting, no prioritizing based on how much you're buying. It's fair in the sense that everyone gets their turn, but it can be inefficient.
📝 Real-World Example
Think of a print queue at your office. Documents get printed in the order they were submitted:
- Document A: 1-page email (arrives at 9:00 AM)
- Document B: 50-page report (arrives at 9:01 AM)
- Document C: 2-page memo (arrives at 9:02 AM)
Result: The 2-page memo has to wait for the entire 50-page report to finish, even though it could have been done quickly!
✅ When to Use FCFS
- • Batch processing systems where fairness matters more than speed
- • Simple embedded systems with predictable workloads
- • Background tasks that aren't time-sensitive
- • When all processes have similar execution times
❌ When NOT to Use FCFS
- • Interactive systems where user responsiveness matters
- • Mixed workloads with very different execution times
- • Real-time systems with deadline requirements
- • When you have short, urgent tasks mixed with long ones
🔍 How to Use the Visualization
Experiment 1: Create processes with similar burst times (all around 3-5ms) and watch how smoothly they execute.
Experiment 2: Add one process with a very long burst time (10ms) as the first process, then add shorter ones. See the "convoy effect" in action!
Watch for: The timeline shows processes as solid blocks - no interruptions or context switching. Notice how later processes must wait for earlier ones to completely finish.
Key Metrics: Pay attention to the average waiting time - it can get quite high with the convoy effect!
📊Process Execution Timeline
Process Legend
Algorithm Information
First-Come-First-Served: Processes execute in order of arrival
📈Performance Metrics
Performance Metrics
Average Turnaround Time
7.75
Average Waiting Time
4.25
Shortest-Job-Next (SJN)
⚡ What is SJF?
Shortest Job First is like being a smart customer at a busy coffee shop. Instead of waiting in a single line, you'd pick the barista who can make your simple espresso in 30 seconds rather than waiting behind someone ordering 5 complicated frappuccinos. It's mathematically proven to give the best average waiting time!
📝 Real-World Example
Imagine an emergency room triage system that prioritizes by treatment time (not severity):
- Patient A: Band-aid needed (2 minutes) - arrives first
- Patient B: Complex surgery (2 hours) - arrives second
- Patient C: Quick prescription (5 minutes) - arrives third
SJF order: A (2 min) → C (5 min) → B (2 hours). Everyone gets treated faster on average!
✅ When to Use SJF
- • Batch processing where you know job durations in advance
- • Database queries where execution time can be estimated
- • Background tasks with predictable runtimes
- • When minimizing average wait time is crucial
- • Scientific computing with known computation times
❌ When NOT to Use SJF
- • Interactive systems where execution time is unpredictable
- • When you have important long-running processes
- • Real-time systems where deadlines matter more than efficiency
- • Fair-share systems where all users need equal access
- • When starvation is unacceptable
⚠️ The Starvation Problem
SJF's biggest weakness: long processes might never get to run if short processes keep arriving! It's like a long movie never starting because 5-minute YouTube videos keep being queued ahead of it.
🔍 How to Use the Visualization
Experiment 1: Create processes with burst times like: 8ms, 2ms, 6ms, 1ms. Watch how SJF reorders them optimally!
Experiment 2: Compare the same processes with FCFS vs SJF - see how much better the average waiting time becomes.
Experiment 3: Create one process with 15ms burst time arriving first, then add many 1ms processes. See the starvation effect!
Watch for: Processes execute in order of burst time, not arrival time. Notice how the waiting time metrics improve dramatically compared to FCFS.
📊Process Execution Timeline
Process Legend
Algorithm Information
Shortest-Job-Next: Processes with shorter burst time execute first
📈Performance Metrics
Performance Metrics
Average Turnaround Time
6.75
Average Waiting Time
3.25
Round Robin (RR)
🎠 What is Round Robin?
Round Robin is like a classroom where the teacher gives each student exactly 2 minutes to present, no matter what. When your time is up, you sit down and the next student gets their turn. If you weren't finished, you go to the back of the line and wait for another 2-minute turn. It's perfectly fair - everyone gets equal time slices!
📝 Real-World Example
Think of a shared computer lab with a 30-minute time limit per person:
- Student A: Needs 45 minutes for research
- Student B: Needs 10 minutes to check email
- Student C: Needs 60 minutes for coding
Round 1: A gets 30 min, B gets 10 min (done!), C gets 30 min
Round 2: A gets remaining 15 min (done!), C gets remaining 30 min (done!)
⚖️ The Time Quantum Dilemma
Too Small (1ms): Lots of context switching overhead - like changing speakers every 10 seconds in a meeting!
Too Large (100ms): Becomes like FCFS - defeats the purpose of sharing time fairly.
Just Right (5-20ms): Good balance between fairness and efficiency. Use the slider to experiment!
✅ When to Use Round Robin
- • Time-sharing systems with multiple interactive users
- • Desktop operating systems for fair multitasking
- • Web servers handling multiple requests fairly
- • When responsiveness is more important than efficiency
- • Gaming systems where all players need fair CPU time
❌ When NOT to Use Round Robin
- • Batch processing where efficiency matters more than fairness
- • Real-time systems with hard deadlines
- • I/O intensive tasks that need to wait for disk/network
- • When context switching overhead is too expensive
- • Single-user systems where fairness isn't needed
🔍 How to Use the Visualization
Experiment 1: Set time quantum to 2ms with processes of 5ms, 3ms, 7ms. Watch the round-robin dance!
Experiment 2: Try the same processes with quantum = 1ms vs 5ms. See how context switching frequency changes.
Experiment 3: Create processes with very different burst times (1ms, 2ms, 10ms) and see how RR keeps everyone moving.
Watch for: Processes get interrupted and resume later. The timeline shows colorful segments - each process gets fair turns. Notice how no process starves, unlike SJF!
⚙️Time Quantum Configuration
Adjust the time quantum to observe its impact on process scheduling:
Process Legend
Algorithm Information
Round Robin: Time quantum = 2
📈Performance Metrics
Performance Metrics
Average Turnaround Time
9.25
Average Waiting Time
5.75
Priority Scheduling
👑 What is Priority Scheduling?
Priority Scheduling is like VIP access at an event. Some processes get the red-carpet treatment while others wait in the general line. The CPU always serves the highest priority process first. But here's the smart part - we use "aging" so that waiting processes gradually become more important, preventing anyone from waiting forever!
📝 Real-World Example
Think of a hospital emergency room with different priority levels:
- Priority 1 (Critical): Heart attack patient - immediate attention
- Priority 2 (Urgent): Broken bone - treated soon
- Priority 3 (Routine): Cold symptoms - can wait
With aging: If the cold patient waits 2 hours, their priority increases so they don't wait all day!
⏰ Understanding Aging
Aging Factor 0.0: No aging - priorities never change. Low priority processes might starve!
Aging Factor 0.5: Moderate aging - waiting processes slowly gain importance.
Aging Factor 1.0: Fast aging - priorities change quickly, almost like Round Robin!
Sweet Spot (0.2-0.5): Good balance between priority respect and starvation prevention.
✅ When to Use Priority Scheduling
- • Real-time systems with different criticality levels
- • Operating systems where system processes need priority over user processes
- • Server environments with different user classes (premium vs basic)
- • Embedded systems with safety-critical tasks
- • When some tasks are genuinely more important than others
❌ When NOT to Use Priority Scheduling
- • Fair-share systems where all processes should be treated equally
- • Batch processing where all jobs have similar importance
- • When you can't determine meaningful priorities
- • Simple embedded systems with uniform task importance
- • When priority inversion could be problematic
🔄 Priority Inversion Problem
Sometimes a high-priority process gets blocked by a low-priority process that's holding a resource. This can cause the high-priority process to wait longer than a medium-priority process - the priorities get "inverted"!
🔍 How to Use the Visualization
Experiment 1: Set aging factor to 0.0. Create processes and see how higher priority ones always go first.
Experiment 2: Use aging factor 0.5. Watch how waiting processes gradually become more important over time.
Experiment 3: Compare aging factor 0.1 vs 0.8 with the same processes. See how it affects the execution order.
Watch for: The process priority values in the sidebar - notice how they change over time due to aging. High priority processes execute first, but aging prevents starvation!
⚙️Aging Factor Configuration
Adjust the aging factor to control priority increase rate:
Process Legend
Algorithm Information
Priority Scheduling: Aging factor = 0.5
📈Performance Metrics
Performance Metrics
Average Turnaround Time
7.75
Average Waiting Time
4.25
Multilevel Feedback Queue (MLFQ)
🎯 What is MLFQ?
Multilevel Feedback Queue is like a smart school system with multiple grade levels. New students (processes) start in the advanced class (high priority queue). If they can't finish their work quickly, they get moved to a lower grade with more time per session. Short, quick tasks stay in the fast lane, while longer tasks get moved to queues with bigger time slices. It's the best of all worlds!
📝 Real-World Example
Think of a tech support system with escalating levels:
- Level 1 (Quick fixes): Password resets, simple questions - 2 minute time limit
- Level 2 (Medium issues): Software troubleshooting - 10 minute time limit
- Level 3 (Complex problems): System analysis - 30 minute sessions
Quick problems get solved fast in Level 1. Complex issues automatically move to Level 2, then 3, getting appropriate time without blocking simple requests!
🏗️ How MLFQ Works
Queue 1 (Highest Priority): Small time quantum (1ms) - for quick, interactive processes
Queue 2 (Medium Priority): Medium time quantum (2ms) - for moderate processes
Queue 3 (Lower Priority): Larger time quantum (4ms) - for longer batch processes
The Magic: Processes automatically find their appropriate queue based on behavior!
🧠 Why MLFQ is Smart
Automatically identifies process types: Interactive vs batch processes separate themselves
Responsive for short tasks: Quick processes get priority and small time slices
Efficient for long tasks: CPU-intensive processes get larger time slices to reduce overhead
Adapts over time: Process behavior determines final queue placement
✅ When to Use MLFQ
- • General-purpose operating systems (Windows, macOS, Linux)
- • Mixed workload environments with interactive and batch processes
- • Desktop systems where responsiveness matters
- • Server systems handling diverse request types
- • When you want automatic process classification
❌ When NOT to Use MLFQ
- • Hard real-time systems where predictability is crucial
- • Simple embedded systems with limited resources
- • Uniform workloads where all processes are similar
- • When implementation complexity isn't justified
- • Systems requiring strict fairness guarantees
🔍 How to Use the Visualization
Experiment 1: Create processes with very different burst times (1ms, 3ms, 8ms). Watch how they end up in different queues!
Experiment 2: Try 2 queues vs 5 queues with the same processes. See how granularity affects performance.
Experiment 3: Create many short processes (1-2ms) and one long process (10ms). Notice how MLFQ keeps the system responsive!
Watch for: Process migration between queues! Short processes stay in high-priority queues, while longer ones move down. This creates natural separation between interactive and batch processes.
⚙️Queue Configuration
Configure the number of priority levels:
Process Legend
Algorithm Information
Multilevel Feedback Queue: 3 priority levels
Performance Metrics
Performance Metrics
Average Turnaround Time
8.00
Average Waiting Time
4.50
Algorithm Selection Guidelines
The choice of scheduling algorithm depends on system requirements and workload characteristics:
- Use FCFS for simple systems with similar process burst times
- Choose SJN for batch processing with known burst times
- Implement Round Robin for time-sharing systems requiring fair CPU distribution
- Apply Priority Scheduling when process importance varies
- Consider MLFQ for systems handling both interactive and batch processes
Experiment with different process configurations and algorithm parameters to observe their impact on system performance metrics.