Visual walkthrough — Processes — PCB, states (new - ready - running - blocked - terminated)

We are trying to answer one question: "One CPU, many jobs — how does the computer keep track of who is doing what, and when?"

Step 1 — One worker, a pile of jobs

WHY start here? Because every complication that follows — states, queues, saving-and-restoring — exists only because the worker has one pair of hands but there are many jobs. If the worker had a hand per job, there would be no states at all. So this single fact is the seed of the entire diagram.

PICTURE. One worker (the CPU) in the middle, three jobs waiting off to the side. Notice: only one job can be in the hands at once.

Step 2 — A job is born: the New state

WHY does "New" deserve its own box? Because setup takes real work (allocating memory, building the bookkeeping record). If we pretended a job was instantly ready, we would ignore the moment where the computer can run out of room and refuse to admit it. "New" is exactly "under construction, not yet allowed into the line."

WHY model the refusal? If there's no room (memory full, too many jobs), the OS may reject the job — it never reaches Ready and is instead sent straight to Terminated (killed before it ever ran). We draw this dashed reject arrow so the diagram truly covers every outcome of New, not just the happy one.

PICTURE. A job appears on the left with a half-finished sticky-note being filled in. It is fenced off from the waiting line — it cannot join yet. A dashed reject arrow shows the no-room path leading straight to Terminated.

Step 3 — Joining the line: Ready, via admit

WHY a separate Ready state, and why a line? Because usually several jobs are all set-up and eager at the same moment, but only one worker exists. Someone must wait. The line is literally the ready queue. Ready = "fully prepared, only missing the CPU."

The transition, in symbols: $\underset{\text{under construction}}{\underbrace{\text{New}}}\stackrel{\text{admit}}{\to }\underset{\text{waiting in line}}{\underbrace{\text{Ready}}}$

• $\text{New}$ — the job whose sticky-note is done.
• $\stackrel{\text{admit}}{\to }$ — the OS's decision that there's room; the only way out of New.
• $\text{Ready}$ — now standing in the ready queue.

PICTURE. The fence opens; the job walks into the ready line behind others. Its sticky-note now reads state = Ready.

Step 4 — Getting the hands: Running, via dispatch

WHY does dispatch come from Ready and nowhere else? Because the hands can only receive a job that is already fully prepared and standing in line. A job in New (still under construction) or Blocked (waiting on something) is not eligible. So there is exactly one door into Running, and it is labelled dispatch, and it starts in Ready.

$\text{Ready}\stackrel{\text{dispatch (scheduler picks it)}}{\to }\text{Running}$

• $\text{Ready}$ — the pool of eligible jobs.
• $\stackrel{\text{dispatch}}{\to }$ — the scheduler's choice; the mechanics of choosing are CPU Scheduling.
• $\text{Running}$ — now, and only now, is real work getting done on the program's instructions.

PICTURE. The scheduler (a small hand-icon) lifts the front job out of the line and places it into the worker's hands. Exactly one job is in the hands.

Step 5 — Losing your turn (but not your ability): Running → Ready, via timeout

WHY back to Ready — why not Blocked? This is the trap most people fall into. The job that got timed-out is perfectly able to keep working — it did nothing wrong, it just ran out of turn. "Able to work but waiting for the hands" is the exact definition of Ready. So it rejoins the line.

WHY is the interrupt the trigger? The job would never choose to stop early. So the hardware interrupt (the clock alarm) is what forcibly wrests the hands back — the timeout transition literally cannot happen without that interrupt firing. That is why the arrow is labelled with both: timeout is the policy, interrupt is the mechanism that enforces it.

$\text{Running}\stackrel{\text{timeout / interrupt}}{\to }\text{Ready}$

• $\text{Running}$ — the job whose slice just expired.
• $\stackrel{\text{timeout}}{\to }$ — the clock interrupt fires; nothing about the job is broken.
• $\text{Ready}$ — straight back into the line, still fully runnable.

PICTURE. The alarm clock rings over the worker; the current job is placed back at the tail of the line while the next job is picked up. (This save-and-swap machinery is Context Switching.)

Step 6 — Waiting on the outside world: Running → Blocked → Ready

WHY step out instead of holding the hands and waiting? Because the hands are precious. If a job held the CPU while a disk crawled for 5 ms, thousands of other instructions could have run. So the job releases the CPU and moves to Blocked. This is why Blocked exists: to not waste the worker on slow I/O.

WHY does the event send it to Ready, not straight back to Running? When the data finally arrives, the worker's hands are almost certainly busy with someone else. The job cannot barge in. It must rejoin the line and wait to be dispatched again.

$\text{Running}\stackrel{\text{I/O request}}{\to }\text{Blocked}\stackrel{\text{event done}}{\to }\text{Ready}\stackrel{\text{dispatch}}{\to }\text{Running}$

• $\text{Running}\to \text{Blocked}$ — the job asked for slow data and stepped aside.
• $\text{Blocked}$ — sitting in the waiting room; not eligible for the hands.
• $\stackrel{\text{event done}}{\to }$ — the disk delivered; an interrupt announces it.
• $\to \text{Ready}$ — back to the tail of the line, never straight to the hands.

PICTURE. The job walks from the hands into a fenced "waiting room" labelled I/O. Later an arrow labelled event done carries it — not back to the hands — but to the tail of the ready line.

Step 7 — Why the sticky-note is non-negotiable (the PCB save/restore)

WHY is this the whole reason PCBs exist? Consider skipping it. Job A stopped at instruction 100. We swap to Job B, which runs up to instruction 540. Now A gets the hands again — but the CPU's PC still reads 540, pointing into B's code. A would leap into a stranger's instructions: garbage, crash. The single field PC is what makes "resume exactly where I left off" possible.

$\text{save: }{\text{PCB}}_A\leftarrow ({\text{PC}}_A,{\text{registers}}_A)\text{restore: }({\text{PC}}_B,{\text{registers}}_B)\leftarrow {\text{PCB}}_B$

• ${\text{PCB}}_A\leftarrow ({\text{PC}}_A,\dots )$ — freeze A's exact position onto its note before letting go.
• $({\text{PC}}_B,\dots )\leftarrow {\text{PCB}}_B$ — thaw B's saved position back into the CPU.

PICTURE. Two sticky-notes side by side. Arrow out of the CPU into A's note (save); arrow from B's note into the CPU (load). Between them, the hands are momentarily empty — that empty moment is pure overhead.

Step 8 — The end, and the degenerate cases: Terminated

WHY does exit go only from Running? To run its final instruction, a job must be the one holding the hands at that moment — you can only reach your own last line while actually executing. So a natural finish is physically only possible from Running: the exit arrow starts there and nowhere else.

Degenerate / edge cases (the diagram must cover every path, even the strange ones):

• Killed while Running: an outside kill (or a fatal error) can end a job mid-execution, sending Running → Terminated without reaching a natural exit. Same destination, different reason.
• Killed while Ready or Blocked: a kill signal can also strike a job that isn't even holding the hands — jumping it from Ready or Blocked straight to Terminated, so it never runs again. A kill can arrive from any live state (Running, Ready, or Blocked).
• Rejected at birth (from Step 2): if there was never room, the job goes New → Terminated via reject, never having run.
• A job that only ever computes (never touches I/O): it simply bounces Running ⇄ Ready via timeouts until done. It never visits Blocked. That is legal — Blocked is optional.
• A job stuck forever in Blocked: if its event never arrives (e.g. broken device), it waits indefinitely. It is not Terminated and not wasting the CPU — it just never wakes. The diagram allows this dead-end.

$\text{Running}\stackrel{\text{exit}}{\to }\text{Terminated}\{\text{Running},\text{Ready},\text{Blocked},\text{New}\}\stackrel{\text{kill / reject}}{\to }\text{Terminated}$

PICTURE. The finished job walks off the far right; its sticky-note is torn up. Dashed "kill" arrows show the shortcut to Terminated from Running, Ready, and Blocked, plus the New reject arrow.

The one-picture summary

Everything above, compressed into the single diagram you should be able to redraw from memory: five boxes, and every legal arrow labelled with the reason it fires — including the dashed kill/reject arrows that can reach Terminated from any live state.

Active Recall