PROGRAM a passive entity: a file on disk containing instructions. One program, one copy. PROCESS an active entity: a program in EXECUTION, with its own memory, registers and state. One program can have MANY simultaneous processes. Opening three terminal windows creates three processes from one /bin/zsh program file. program : process :: class : object :: recipe : meal A PROCESS CONSISTS OF: TEXT the program code (read-only, shareable) DATA global and static variables HEAP dynamically allocated memory (malloc/new), grows up STACK call frames, locals, return addresses, grows down REGISTERS program counter, stack pointer, general registers MEMORY LAYOUT (conventional picture): high address ┌──────────────┐ │ STACK │ grows DOWN ├──────────────┤ │ ↓ │ │ (unused) │ │ ↑ │ ├──────────────┤ │ HEAP │ grows UP ├──────────────┤ │ DATA │ globals, statics ├──────────────┤ │ TEXT │ the code low address └──────────────┘ The gap between stack and heap is why a stack overflow and a heap exhaustion are different failures, and why they grow toward each other.

NEW the process is being created; its PCB exists but it is not yet admitted to the ready queue READY runnable, waiting only for a CPU RUNNING currently executing on a CPU BLOCKED waiting for an event (I/O completion, a signal, a lock). CANNOT run even if a CPU is free. TERMINATED finished; the PCB may linger until the parent reaps it (zombie) THE SIX LEGAL TRANSITIONS — and note which pairs are missing: NEW → READY admit (the long-term scheduler decides) READY → RUNNING dispatch (the short-term scheduler picks) RUNNING → READY preempt (timer interrupt or a higher-priority process arrives) RUNNING → BLOCKED the process REQUESTS something it must wait for — it does this to itself BLOCKED → READY the awaited event occurs; note it goes to READY, NOT straight to RUNNING RUNNING → TERMINATED exit, or killed IMPOSSIBLE, and this is the standard exam trap: ✗ BLOCKED → RUNNING an unblocked process must queue for the CPU like everyone else ✗ READY → BLOCKED you cannot wait for something you have not yet asked for WHO CAUSES EACH TRANSITION: RUNNING → BLOCKED the PROCESS itself (voluntary) RUNNING → READY the OS (involuntary preemption) BLOCKED → READY the OS, on an interrupt from the device That split matters: a process chooses to block, but never chooses to be preempted. TWO EXTRA STATES in real systems (seven-state model): SUSPENDED READY swapped out to disk but runnable SUSPENDED BLOCKED swapped out and waiting Swapping moves whole processes out of memory under pressure; the medium-term scheduler makes that decision.

The PCB (also "process descriptor", or task_struct in Linux) is the data structure holding everything the OS knows about a process. It IS the process, as far as the kernel is concerned. PROCESS IDENTIFICATION pid this process's id ppid parent's id uid, gid owning user and group PROCESSOR STATE (saved on every context switch) program counter general-purpose registers stack pointer processor status word / condition flags PROCESS CONTROL INFORMATION state NEW/READY/RUNNING/BLOCKED/TERMINATED priority and scheduling parameters memory info page tables / segment table, base+limit open files the file descriptor table accounting CPU time used, wall time, limits I/O status devices held, pending requests signal handlers and pending signals SIZE: Linux's task_struct is roughly 4–8 KB. With 599 processes on this machine that is a few megabytes of pure bookkeeping — the price of multiprogramming. WHERE IT LIVES: in kernel memory, in a process table. A user process cannot read or write its own PCB directly; it can only observe parts of it through system calls (getpid, getrusage) or through /proc on Linux. CONTEXT SWITCH — the operation that uses the PCB: 1. save the current process's registers into its PCB 2. update its state (RUNNING → READY or BLOCKED) 3. select the next process (the scheduler) 4. load the new process's registers from its PCB 5. switch the memory map (page-table base register) 6. resume COST: typically 1–10 µs, and it is PURE OVERHEAD — no user work happens during a switch. Worse, the new process starts with a cold cache and TLB, so the real cost includes hundreds of subsequent cache misses. That indirect cost usually exceeds the direct one. This is why a very short time quantum is bad: if the quantum is 1 ms and a switch costs 10 µs, 1% of the CPU is lost to switching. At a 100 µs quantum it would be 10%.

# Verified on Darwin 25.5.0 arm64, 10 cores, 16 GiB.

ps ax | wc -l
# 599        <- 599 processes on an IDLE desktop

sysctl -n hw.ncpu
# 10         <- so at most 10 are RUNNING at any instant;
#               the other ~589 are READY or BLOCKED.

sysctl -n kern.clockrate
# { hz = 100, tick = 10000, ... }
#   The timer interrupt fires every 10 ms. That interrupt is
#   what makes the RUNNING → READY preemption transition
#   possible — without it, a process that never blocks would
#   hold the CPU forever.

ps -o pid,ppid,stat,pri,%cpu,rss,command -p 1
# PID  PPID STAT PRI %CPU   RSS COMMAND
#   1     0 Ss    37  0.0  ...  /sbin/launchd
#
# Every field here is read straight out of the PCB:
#   PID/PPID → process identification
#   STAT     → the state (S = sleeping/blocked, R = running,
#              Z = zombie, T = stopped)
#   PRI      → scheduling priority
#   RSS      → resident memory, from the memory-management info
#
# pid 1 with ppid 0 is the root of the process tree. Every
# orphaned process is re-parented to it.

THE RATIO IS THE POINT: 599 processes, 10 cores. at most 10 RUNNING the rest READY (want CPU) or BLOCKED (waiting on something) On an idle machine almost all 589 are BLOCKED — sleeping on a timer, waiting for network input, waiting for a keypress. That is why an idle desktop uses almost no CPU despite running hundreds of processes, and it is the practical form of the 1 − pⁿ argument from the evolution topic. READING ps STATE CODES (BSD/macOS): R running or runnable S sleeping (interruptible) — the BLOCKED state I idle (sleeping > 20 s) T stopped (SIGSTOP, e.g. Ctrl-Z) U uninterruptible wait — usually disk I/O Z zombie: terminated but not yet reaped A process stuck in U is the classic "cannot be killed" case: it is inside a kernel I/O operation and will not even process SIGKILL until that returns. `kill -9` genuinely does nothing, which surprises people.