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

Ready. By the definition of Ready, the process is fully set up and only waiting for the scheduler to hand it a core. It is not Blocked, because Blocked means waiting on an external event (like I/O), not merely waiting for a turn on the CPU.

False. The code (the text segment) lives in the process's memory image / address space. The PCB stores metadata plus a pointer to that memory. The PCB is small; the code can be megabytes.

The two critical fields are the Program Counter (PC) — which instruction is next — and the CPU registers — the working values mid-computation. (The full PCB also holds state, PID, memory map, I/O status, scheduling info, but for correct resumption of the calculation those two are the heart.)

Running → Ready, via the timeout / preempt transition. The slice ended, so it loses the CPU, but it is still perfectly able to run — nothing external is blocking it — so it rejoins the ready queue, not Blocked.

Would priority change the target state? No — the destination is still Ready either way. Priority only changes the cause of preemption:

• Time-slice expiry (this problem): the clock interrupt forces the switch even if nobody better is waiting.
• Priority preemption: a higher-priority process becoming Ready can also preempt the runner before its slice ends. Both are flavours of the same Running → Ready edge — the preempted process is always still runnable, so it always returns to the ready queue, never to Blocked. See CPU Scheduling for how priority drives who is dispatched next.

Running → Blocked, via the wait / I/O transition. The data is slow; spinning the CPU waiting for it would waste cycles, so the process voluntarily yields the CPU and steps out of the ready line until the disk signals completion. See Ready Queue and I-O Queues for where it waits.

Blocked → Ready, via event done. The wait is over, but the CPU may be busy running someone else. The scheduler must re-select this process, so it can only re-enter the queue (Ready). It reaches Running later only via a fresh dispatch.

Track the ready queue and remaining work.

Finish times: P3 finishes at t = 5 ms, P1 at t = 6 ms, P2's I/O (its final work) completes at t = 8 ms.

Key contrast: P1 was preempted → Ready (still runnable). P2 requested I/O → Blocked (waiting on an event). Same "stopped running," opposite states.

List every CPU handoff, including the very first one out of idle:

1. t=0: idle → P1 (the initial dispatch — the CPU was idle before anyone ran)
2. t=2: P1 → P2
3. t=3: P2 → P3
4. t=5: P3 → P1
5. t=6: P1 → idle

That is 5 context switches. The initial idle→P1 dispatch is easy to forget, but by the counting rule ("idle→process also counts") it is a genuine state load. After t=6 the core stays idle; P2 needs no more CPU, so no further switch occurs. Each switch is pure overhead — see Context Switching.

On dispatch, the CPU loads the PC from P1's saved PCB value — but that save was skipped, so the hardware PC still holds 540, the leftover from B. P1 therefore resumes execution at address 540, which is inside B's code region (500–800), not P1's. P1 begins executing B's instructions on P1's data → garbage results or an immediate crash (illegal access / wrong instruction stream).

Correct behaviour: the PCB must have stored PC = 100; on resume the CPU loads 100 and P1 continues exactly where it paused. This is why the Program Counter is the single most critical field for correct resumption.

Ask the derivation question from the parent note: "to resume this exact computation, what must I remember?"

• Program Counter — so it resumes at the right instruction (L4.1 shows the disaster otherwise).
• CPU registers — mid-calculation working values must survive the pause.
• Process State — the OS must know it is Ready/Running/etc. to schedule it correctly.
• PID — a unique handle so the OS can name and find this PCB among many.
• Memory base/limit (address-space pointer) — so the CPU knows where this process's data lives when restored.

Everything else (open-file table, I/O status, accounting, priority) is droppable for a pure calculator because it has no files, does no I/O, and we assume equal scheduling. The five above are the irreducible core.

Definitions in play: Running means the process currently holds a CPU core. A process obtains a core only through the dispatch transition, and dispatch selects exclusively from processes in the Ready queue (that is what the ready queue is: the pool the scheduler chooses from).

The argument, in plain steps:

1. To be Running, a process must have been dispatched (that is the only edge into Running from inside the system).
2. Dispatch only ever picks from the Ready queue.
3. So to become Running, a process must first be in Ready.
4. A Blocked process's awaited event completing triggers exactly one edge — event done — whose target is Ready, not Running (typically signalled by an interrupt).
5. Therefore the only legal path from Blocked to Running is: Blocked → (event done) → Ready → (dispatch) → Running.

Written compactly, that path is: $\text{Blocked}\stackrel{\text{event done}}{\to }\text{Ready}\stackrel{\text{dispatch}}{\to }\text{Running}$ which in words reads "the event finishes, sending the process to Ready; the scheduler then dispatches it to Running." A direct Blocked → Running edge would require the scheduler to dispatch a process that is not in the ready queue, contradicting step 2. Hence the log entry is impossible — a state (Ready) was omitted from the log. $■$

(a) Killed while Blocked. Termination is not a normal event-completion. A kill causes Blocked → Terminated directly: the process is being destroyed, so it does not re-enter Ready — there is nothing to schedule. (The event-done rule "must pass through Ready" governs resumption, not destruction.) The pending I/O is abandoned/cleaned up and the PCB is reclaimed.

(b) Infinite slice. With no timeout ever firing, the timeout/preempt transition never triggers. A dispatched process runs until it voluntarily blocks (I/O) or exits. This degenerates round-robin into non-preemptive scheduling (run-to-completion / cooperative), the FCFS-like behaviour in CPU Scheduling.

(c) Zero-work process. Recall the five states from the top of the page: New (being created), Ready, Running, Blocked, Terminated. A zero-work process still traverses the minimal path, just with no Running dwell time:

• New — its PCB is being allocated (creation always starts here).
• New → Ready (admit) — creation done, it becomes runnable.
• Ready → Running (dispatch) — it is handed a core.
• Running → Terminated (exit) — it occupies the core for effectively 0 time and immediately exits.

It never enters Blocked (no I/O) and never suffers a timeout (nothing to time out on). There is no legal shortcut skipping New, Ready, or Running.

In L3.1, what is P3's finish time? ::: t = 5 ms. In L3.1, what is P1's finish time? ::: t = 6 ms. In L3.2, how many context switches occur (counting the initial idle→P1)? ::: 5. In L4.1, what wrong PC value does P1 resume at? ::: 540 (leftover from process B). A process killed while Blocked goes to which state? ::: Terminated (directly, not via Ready). Infinite time-slice turns round-robin into what? ::: Non-preemptive / run-to-completion scheduling.