A process issues a read() system call to load data from disk. While it waits, another process runs. When the disk read completes, where does the first process go?
ADirectly back to running — it resumes from where it left off as soon as the I/O finishes
BTo the ready queue — the scheduler decides when it next receives CPU time
CTo the blocked state again until an explicit wake-up call from the user
DTo the terminated state because the I/O operation has completed
When I/O completes, an interrupt fires and the OS moves the process from blocked to ready — not directly to running. The scheduler still decides which ready process runs next; the formerly-blocked process must compete with all other ready processes for CPU time. Assuming it jumps directly to running confuses two separate mechanisms: the I/O completion interrupt (which unblocks the process) and the scheduler dispatch (which grants CPU time). These are independent events.
Question 2 Multiple Choice
What causes a running process to transition to the ready state rather than the blocked state?
AThe process calls exit() to finish execution
BThe process issues a blocking system call (e.g., waiting for keyboard input)
CA timer interrupt preempts the process at the end of its CPU time slice
DThe process encounters a page fault requiring a disk read
Preemption by timer interrupt sends the process from running back to ready — it has done nothing wrong and is still fully capable of running; the OS simply decided another process should have a turn. In contrast, a blocking system call (option B) or a page fault (option D) sends the process to blocked, because it genuinely cannot proceed until an external event occurs. The key distinction is whether the process has work it could do right now (ready) or is waiting for something it needs (blocked).
Question 3 True / False
A blocked process consumes CPU time while waiting for its I/O request to complete.
TTrue
FFalse
Answer: False
False. A blocked process is parked entirely — it is not in the run queue and will not be selected by the scheduler. It consumes no CPU time. This is the efficiency gain of blocking I/O: while one process waits for slow I/O, the CPU can run other processes productively. The OS maintains a separate waiting structure (e.g., a wait queue associated with the I/O device) for blocked processes, distinct from the ready queue from which the scheduler picks.
Question 4 True / False
When the event a blocked process was waiting for occurs, the OS may move it directly to the running state if no other process is using the CPU.
TTrue
FFalse
Answer: False
False. When an event completes, the OS always moves the process from blocked to ready — never directly to running, even if the CPU is idle. The scheduler then selects the highest-priority ready process to run. This two-step indirection (blocked → ready → running) keeps the scheduling decision centralized in the scheduler rather than scattered across interrupt handlers. In practice, the formerly-blocked process may be dispatched almost immediately if it has high priority, but the state machine still passes through 'ready.'
Question 5 Short Answer
What is the fundamental difference between a process in the ready state and one in the blocked state, and why does that difference matter for the scheduler?
Think about your answer, then reveal below.
Model answer: A ready process has everything it needs to execute and is simply waiting for CPU time. A blocked process is waiting for an external event (I/O completion, a timer, a signal) and cannot make progress even if given the CPU. The scheduler only considers ready processes when deciding who to run next — blocked processes are invisible to it. This matters because assigning CPU time to a blocked process would be wasted: the process would immediately suspend again. By separating these states, the OS ensures the CPU is always given to a process that can actually do useful work.
The distinction is not about priority or importance — it is about whether the process is 'runnable right now.' A high-priority process waiting for a network packet is blocked; a low-priority process that just needs CPU time is ready. The scheduler serves the ready queue exclusively. When blocked processes unblock (their event occurs), they join the ready queue and the scheduler can then consider them. This separation is the mechanism that allows an OS to keep the CPU busy even when some processes are stuck waiting for slow I/O.