Loading...
Follow one process as it waits, runs and blocks. Explain the operating system’s service and the state that must survive when the CPU switches to another task.
What you'll be able to do
The operating system manages hardware resources and provides interfaces through which applications and users request services. Its user interface can be graphical or command-based. User management handles accounts and appropriate access rights; a signed-in identity is not permission to read every other user’s files. Peripheral management coordinates device access, commonly with device-specific drivers.
Process management schedules execution and retains process state. Memory management tracks allocation and access so programs can use their intended working space without freely overwriting one another. These responsibilities interact: a request to read a file may require a permission check, a buffer allocation and a device operation while the requesting process waits. Name the mechanism needed by the scenario rather than listing OS functions without connection.
A process is a running instance of a program with execution state and resources. In a simple lifecycle, a new process is admitted to ready, meaning it can run when selected. Dispatch changes ready to running. A running process that requests unavailable input/output becomes blocked, meaning it cannot make progress merely by receiving CPU time.
When the awaited event completes, blocked becomes ready, not automatically running. A scheduler may then dispatch it. Timer preemption can move running back to ready while preserving unfinished work. A completed process becomes terminated. The exact state names vary by model; use the question’s diagram and label each transition with a cause. A process is not blocked merely because another ready process currently has the CPU.
On one CPU core, multitasking can interleave tasks through time sharing. A timer interrupt gives the OS an opportunity to regain control. The system preserves the interrupted context, including the next instruction address and required register/status/stack information, and the scheduler can select another ready process. Restoring that process’s context lets it resume its own computation rather than inherit the previous task’s values.
A device interrupt can report that a blocked task’s I/O event has completed. Handling the event and selecting the next task are related but distinct work. Context switching consumes time and does not itself complete the application’s calculations. Multiple cores can add physical parallelism, but one core’s rapid switching is concurrency through interleaving. Account for priorities, handler costs and the model’s stated preemption rules.
| From | Cause | To |
|---|---|---|
| New | Admitted and prepared | Ready |
| Ready | Scheduler dispatch | Running |
| Running | Time slice/preemption | Ready |
| Running | Wait for I/O/event | Blocked |
| Blocked | Awaited event completes | Ready |
| Running | Finishes | Terminated |
Attempt the task before opening its worked response. Record each change of state, explain the rule used, and check the result against the original requirements. Code examples labelled Python 3 use that language’s conventions; pseudocode states its own assumptions.
Common mistakes to avoid
Key takeaways
Test yourself
Answer a few questions, then review anything you missed.
Start with the quiz above to check the key ideas. You can also choose another topic from the practice library.