Skip to main content

The Process Control Block and Kernel State

What This Concept Is​

The Process Control Block (PCB) is the kernel's data structure for one process. On Linux it is a struct task_struct. On most teaching OSes it has roughly these fields:

  • identification: pid, ppid, user/group ids
  • register snapshot: all CPU registers when the process is not running
  • scheduling state: state (RUNNING, READY, BLOCKED, ZOMBIE), priority, nice, CPU affinity, run-queue link
  • memory info: pointer to the page-table root, memory-mapping list
  • file state: file descriptor table, current working directory
  • signal state: pending signals, signal handlers, signal mask
  • accounting: user/system CPU time, start time
  • pointers: to parent, children, and sibling PCBs (the process tree)

The PCB is the truth about a process while it is not executing. The CPU registers are the truth while it is.

Why It Matters Here​

Every scheduling decision reduces to: "move some bits between PCBs and CPU registers, then jump." Context switching is exactly "save registers into PCB A, load registers from PCB B, return to user mode." If you cannot picture the PCB, you cannot picture the switch.

The kernel also uses PCBs to build the process state diagram:

     ┌────────┐    accepted    ┌───────┐
     │  NEW   │───────────────>│ READY │◄────┐
     └────────┘                └───────┘     │
                                   │         │
                            dispatch│         │ I/O or event
                                   ▼         │  complete
                              ┌─────────┐    │
                              │ RUNNING │────┘
                              └─────────┘
                                   │
                               exit │    I/O wait
                                   ▼    or block
                              ┌──────────┐     ┌─────────┐
                              │ ZOMBIE/  │     │ BLOCKED │
                              │ TERMIN.  │     │(waiting)│
                              └──────────┘     └─────────┘

Every transition is an edit to the PCB: "mark READY", "mark BLOCKED on socket fd=5", "mark ZOMBIE with exit code".

Concrete Example​

Two processes A (PID 101) and B (PID 102) both want the CPU. Kernel state (simplified):

task_struct A:  pid=101  state=READY     regs={...}  pri=20  in_queue=runq[0]
task_struct B:  pid=102  state=RUNNING   regs=<live in CPU>  pri=20

A timer interrupt fires. The kernel:

  1. Sets B.state = READY, B.regs = current CPU registers.
  2. Pushes B back onto a run queue.
  3. Pops A from a run queue, sets A.state = RUNNING.
  4. Loads CPU registers from A.regs.
  5. Returns from interrupt into user mode at A.regs.pc.

No user code in A "knows" the pause happened. The PCB is what made the resumption possible.

Common Confusion / Misconception​

"The PCB is stored in the process's own memory." No. It is in kernel memory, deliberately protected from the user process. If user code could edit its own PCB, it could raise its own priority, forge a PID, or escape scheduling entirely.

Also: zombie processes are not running. A ZOMBIE PCB lingers only so the parent can read the child's exit status via wait. The address space is already gone.

How To Use It​

Whenever a question sounds like "what happens to X when Y occurs," translate into PCB edits:

  1. Which fields change?
  2. Which linked lists (run queue, wait queue, children list) are mutated?
  3. Which CPU registers need to be reloaded?

If you cannot describe the edit in one or two sentences, the question is not answered yet.

Check Yourself​

  1. Name five fields of a PCB and explain when each is read or written.
  2. What is the difference between BLOCKED and READY?
  3. Why is the register snapshot only valid when the process is not running?

Mini Drill or Application​

Draw the state transitions for this trace and mark which PCB field changes at each step:

  1. Process P is forked (starts READY).
  2. P is dispatched and runs.
  3. P calls read on a slow disk and blocks.
  4. Disk returns data via interrupt.
  5. P runs again and exits.
  6. Parent calls wait.

Read This Only If Stuck​