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

True — Ready means "has everything except a free core." If it needed data from disk too, it would be Blocked, not Ready.

False — a Blocked process holds zero CPU. That is the entire point: instead of idle-spinning on the core it steps aside so the scheduler can run someone useful.

False — exactly one process runs per core at a time. Multiple "Running" only makes sense with multiple cores.

True — the ready queue is a queue precisely because many processes can be dispatch-eligible simultaneously; the CPU picks one.

False — the code (text segment) lives in the process's memory image; the PCB stores metadata plus a pointer to that image. The PCB is small even for a huge program.

False — there is one PCB per process. Running the same program twice creates two processes, two PIDs, two PCBs.

True — dispatch is defined as Ready → Running. Even a brand-new process goes New → Ready → Running; nothing jumps New → Running.

False — timeout sends it to Ready. It is still perfectly able to run; it merely lost its turn. Blocked is reserved for waiting on an external event.

False — it goes Blocked → Ready. The core may be busy with another process, so the scheduler must re-select it first.

True — the state is recorded as Terminated in the PCB; the OS keeps that record until the exit info is collected, then reclaims it. It isn't erased the instant the process ends (see the Zombie edge case).

False — the save (PC + registers into the old PCB) and restore (from the new PCB) is pure overhead; no user instructions execute during it. Too many switches waste CPU.

False — some are voluntary (calling I/O → Blocked), but preemption (Running → Ready) is forced on the process by a timer interrupt handled by the kernel, not requested by it.

The middle-to-last hop is illegal. Correct path: Running → Blocked → Ready → Running. Blocked never jumps straight to Running.

The PC (Program Counter) is saved into the process's PCB, not the queue. The ready queue holds pointers to PCBs, not register values.

A created process becomes Ready first (the "admit" transition), then Running via dispatch. No New → Running edge exists.

No such transition. Waiting for the CPU is Ready; it never becomes Blocked from mere queue delay. Blocked requires an external event to wait on.

Fatal — the process must resume exactly where it stopped. Losing the registers/PC corrupts its mid-calculation state and it would execute garbage.

Actually possible — a process can be killed while blocked (e.g. the OS or a signal terminates it). Its pending I/O is abandoned and the PCB is reclaimed.

Wrong split — the rest are mostly Ready (waiting for a core), not Blocked. Blocked is only for those awaiting an event.

No — the event completion (I/O interrupt) moves Blocked → Ready. The scheduler's job is choosing among Ready processes for the CPU.

Because the CPU may already be executing another process; forcing a resume would require kicking that one off arbitrarily. Re-queuing keeps scheduling fair and consistent.

It names the next instruction. Without it, on resume the CPU has whatever address the previous process left, so the process jumps into the wrong code and crashes.

They wait on different things. Ready is dispatch-eligible now; Blocked cannot run until an event fires. The scheduler must never dispatch a Blocked process, so they need distinct labels.

Creation takes work — allocate the PCB, set up the address space, load the image. During that setup the process isn't dispatchable yet, so it sits in New.

Each switch is overhead with no user progress; if switches dominate, the CPU spends its time saving/restoring PCBs instead of doing work — throughput collapses.

It hasn't finished — it just used its time-slice. It still holds valid state and needs the CPU again, so it rejoins the ready queue.

The PCB is kernel bookkeeping; if a process could rewrite its own state/PID/priority it could cheat the scheduler or corrupt the system. It therefore lives in kernel space — memory the kernel (the trusted core of the OS) protects from user programs.

The OS must answer "what is this process doing?" instantly for scheduling, and the PCB is the one per-process record it already holds, so the state lives there beside the PC and registers.

It is stuck in (or fails out of) New; admission to Ready only happens once resources are allocated. It never becomes Ready if setup can't complete.

New → Ready → Running → Terminated. It never blocked; the shortest real lifecycle still passes through Ready and Running.

Yes, on timeout/preempt (timer interrupt) it goes Running → Ready even with no rivals, then is re-dispatched. It never enters Blocked because it never waits on an event.

It Blocks only if the I/O is synchronous and the data is not yet available (e.g. an actual disk read that must go to the platter). If the request is served instantly from an OS cache (data already in memory) or is asynchronous, the call returns without waiting, so the process stays Running and skips the Blocked → Ready path entirely.

On systems like Linux, when a process finishes it becomes a Zombie — it has stopped executing but its PCB is kept alive so its parent can read its exit code (called "reaping"). It sits between Terminated and full removal; once the parent reaps it, the PCB is finally reclaimed. This is a real-world refinement of the single "Terminated" state.

Yes — Ready → Terminated is valid; a process can be terminated from Ready or Blocked, not only from Running. Its PCB is then reclaimed.

Yes — momentarily during a context switch, or when all user processes are Blocked (the idle process fills the gap). "Running" isn't guaranteed to be occupied by user work.

Nothing runnable exists, so the CPU runs the idle process (a special always-ready placeholder) until an event moves someone Blocked → Ready.