An operating system uses a scheduling algorithm that achieves 99% CPU utilization — the CPU is almost never idle. Can we conclude that interactive users will experience fast response times?
AYes — high CPU utilization means work is being done efficiently, which directly benefits all users
BNo — a compute-bound job could monopolize the CPU, leaving interactive processes waiting even though utilization is high
CYes — CPU utilization and response time always improve together under any scheduling algorithm
DNo — CPU utilization above 95% causes thermal throttling, which degrades response time
CPU utilization measures how often the CPU is busy — it says nothing about which processes are getting that CPU time. A single long-running batch job could keep the CPU at 99% utilization while short interactive jobs wait in the ready queue. From the interactive user's perspective, response time (time from request to first output) could be terrible. This is the key insight: different metrics measure different things, and optimizing one can leave others unchanged or worsened. Non-preemptive scheduling in particular can produce high utilization with terrible interactive response time.
Question 2 Multiple Choice
Shortest-Job-First (SJF) scheduling is described as 'optimal.' What exactly is it optimal for, and what is its main practical limitation?
AIt minimizes average CPU utilization; the limitation is that it requires preemption hardware support
BIt minimizes average waiting time; the limitation is that it requires knowing each job's burst time in advance, which is rarely available
CIt maximizes throughput for I/O-bound processes; the limitation is that it starves CPU-bound processes indefinitely
DIt minimizes response time for all processes; the limitation is that it cannot handle processes that arrive after scheduling begins
SJF is provably optimal for minimizing average waiting time — by seeing the shortest jobs first, you reduce the total time other jobs spend waiting behind them. But this requires knowing each process's CPU burst time before it runs, which is not available in practice (the OS doesn't know in advance how long a process will compute before blocking on I/O). Practical implementations estimate burst times from historical behavior. SJF can also cause starvation: if short jobs keep arriving, long jobs may never get scheduled.
Question 3 True / False
A scheduler that maximizes CPU utilization will necessarily minimize the waiting time experienced by processes in the ready queue.
TTrue
FFalse
Answer: False
CPU utilization and waiting time measure entirely different things and can move in opposite directions. High CPU utilization means the processor is rarely idle — but if a single long job is running, every other process waits in the ready queue the entire time. Waiting time (time spent ready but not running) can be very high while utilization is also high. To minimize waiting time, you need to consider scheduling order and fairness, not just keep the CPU busy. This is why real operating systems balance multiple metrics simultaneously, accepting imperfect utilization in exchange for acceptable waiting and response times.
Question 4 True / False
In preemptive scheduling, the operating system can interrupt a currently-running process and move it back to the ready queue before it voluntarily yields the CPU.
TTrue
FFalse
Answer: True
This is the defining feature of preemptive scheduling. The OS retains the ability to interrupt a process — typically when a higher-priority process becomes ready or when a time quantum expires — and reassign the CPU to another process. This is essential for interactive systems: without preemption, a compute-bound process could run indefinitely while a user's keypress waits unprocessed. Preemption requires saving the interrupted process's state (context switch) so it can resume correctly later. Non-preemptive scheduling, by contrast, requires a process to voluntarily release the CPU.
Question 5 Short Answer
Explain the difference between turnaround time and response time. Why does this distinction matter for different types of computing workloads?
Think about your answer, then reveal below.
Model answer: Turnaround time is the total elapsed time from when a process is submitted to when it completes. Response time is the time from submission to the first output or first CPU allocation. For batch workloads (e.g., scientific simulations), turnaround time matters — users want the job done fast. For interactive workloads (e.g., a text editor), response time matters — users need immediate feedback to keystrokes even if the overall session takes a long time. A scheduler could achieve good turnaround time while having terrible response time (run each job to completion in order) or vice versa.
This distinction drives real scheduler design decisions. Interactive operating systems (like desktop OSes) prioritize response time by preempting long jobs and giving I/O-bound processes quick CPU access — users notice a 100ms keyboard lag but not a 10% increase in total session time. Batch schedulers on HPC clusters prioritize turnaround time and throughput, sometimes accepting poor response time in exchange for completing more work per unit time. Multi-level feedback queues try to achieve both by dynamically classifying processes based on their observed behavior.