The Core Idea
A Process Is Always in Exactly One State
A process is a program in execution — not just the static code sitting on disk, but the code actively running, along with its current memory, register values, and everything else needed to represent its execution at this exact moment. At any given time, a process exists in exactly one of several defined states, and the operating system's scheduler is responsible for moving processes between these states based on CPU availability, I/O requests, and other events.
Understanding this life cycle is foundational because nearly every other OS concept — scheduling, context switching, deadlocks, synchronization — is really about managing HOW and WHEN processes move between these states, especially when many processes are competing for a limited number of CPU cores.
💡 Memory Trick
Picture a single doctor's office with one exam room. NEW is a patient just walking in and checking in at the front desk. READY is a patient sitting in the waiting room, fully prepared to be seen, just waiting for the exam room to free up. RUNNING is the patient currently in the exam room being actively treated. WAITING is a patient sent to get a lab test done elsewhere — they can't continue their appointment until that test result comes back, no matter how free the exam room becomes in the meantime. TERMINATED is the patient who has finished their appointment entirely and left the building.
The Five States
What Each State Means and How Processes Move Between Them
1
New
The process is being created — the OS is setting up its initial resources (memory space, process control block) but it hasn't yet been admitted to the pool of processes eligible to run.
2
Ready
The process has everything it needs to run and is waiting only for the CPU to become available. Many processes can be in the Ready state simultaneously, all waiting their turn — the scheduler decides which Ready process gets the CPU next.
3
Running
The process is actively executing on a CPU core right now. On a single CPU core, only one process can be in this state at any given instant (though modern multi-core systems can have one Running process per core simultaneously).
4
Waiting (Blocked)
The process cannot continue executing because it's waiting for some external event — most commonly an I/O operation to complete (reading a file, waiting for network data). Critically, a Waiting process does NOT return to Running just because the CPU becomes free; it can only leave Waiting once its specific event actually completes, at which point it moves to Ready, not directly back to Running.
5
Terminated
The process has finished executing (or was forcibly killed), and the OS begins reclaiming its resources. This is the final state — a terminated process does not transition to any other state.
The Key Transitions
Which Moves Are Possible, and Which Aren't
A crucial, frequently-tested detail: a Running process can move to Ready (if the scheduler preempts it to let another process run) or to Waiting (if it needs to block on I/O), but it can NEVER move directly from Waiting back to Running — it must first return to Ready and wait its turn to be scheduled again, even after its I/O completes. This is exactly why a process that's been waiting for disk I/O doesn't instantly resume the moment that I/O finishes; it re-enters the Ready queue and competes with other Ready processes for the next available CPU slot.
This state machine is what the scheduler actively manages, deciding at each opportunity which Ready process to move into the Running state — the specific algorithm used for that decision is exactly what the Scheduling Algorithms lesson covers in depth.
🖥️ Applied Scenario
A process is actively running and issues a request to read a large file from disk, and you're tracing exactly what states it moves through afterward.
1
The moment the process issues the disk read request, it moves from Running to Waiting, since it cannot proceed until that I/O operation completes — the CPU is freed up for other processes in the meantime.
2
Once the disk I/O actually completes, the process does NOT jump straight back to Running — it instead moves to Ready, joining the queue of other processes also waiting for CPU time.
3
The scheduler eventually selects this now-Ready process (based on whatever scheduling algorithm is in use) and moves it into Running, allowing it to actually continue executing with the file data now available.
4
Conclusion: the process passed through Running → Waiting → Ready → Running, never transitioning directly from Waiting to Running — it always had to pass through Ready first, waiting its turn even after its I/O was already complete.
📌 Exam Application
Exam questions frequently ask you to trace a process through a described sequence of events (I/O requests, scheduler preemption, completion) and identify which state it's in at each point, or to identify which state transitions are valid versus invalid. A commonly tested detail is confirming that Waiting can only transition to Ready, never directly to Running.
⚠️ Most Common Process Life Cycle Mistakes
The most common mistake is assuming a process moves directly from Waiting back to Running the instant its I/O completes — it must always pass through Ready first and be selected by the scheduler, even if the CPU happens to be completely idle at that exact moment. Another frequent error is assuming only one process can be in the Ready state at a time — many processes can be simultaneously Ready, all waiting for their turn at the CPU; only the Running state is limited to one process per CPU core.
✓ Quick Self-Test
Can you list all 5 process states and correctly identify which state transitions are valid versus invalid? Given a described sequence of events for a process (creation, scheduling, I/O request, I/O completion, termination), can you correctly trace which state it's in at each point?
Next Lesson
Deadlock Conditions
→
← All Operating Systems Lessons