What a Process Actually Is (Not 'A Running Program')

"A process is a running program" isn't wrong — it's just not specific enough to build anything on. If a process is just "a running program," what exactly gets saved when the OS pauses it? What exactly gets copied when it forks? Those don't have answers until you can name the actual pieces.

The four things that make up a process

1. A unique process identifier (PID).
2. A memory image in RAM — code and data from the executable, plus a stack and heap allocated at runtime. Stack handles function execution; heap handles dynamic allocation.
3. An execution context — the CPU register values. This is the part people skip, and it's the one that matters most for everything that comes after (context switches, scheduling):
   • Program Counter (PC) — address of the next instruction
   • General-purpose registers — temporary data, intermediate results, function arguments
   • Stack Pointer (SP) — where the process's stack currently sits
   • CPU flags/status register — zero, carry, sign, overflow — needed to resume conditional instructions correctly
   • All of this lives in a kernel structure called the Process Control Block (PCB) — struct proc in xv6, task_struct in Linux
4. Ongoing I/O state — open files, active network connections, whatever the process has a handle on.

Every later mechanism is just "do something with one or more of these four things." A context switch swaps #3. A fork copies #2 and #3. A zombie process is #1 persisting in a table after #2 and #3 are gone.

How a process actually comes into existence

1. The executable sits on disk — machine code, data, metadata, an entry point.
2. The user runs it; the OS creates the process — PID, initial state, empty register set, file descriptor table, scheduling info.
3. The OS creates a virtual address space for it.
4. The OS loader maps the program's code and data into that address space (and any required shared libraries).
5. The process becomes READY.
6. The CPU scheduler eventually picks it to execute.

The program on disk and the process in memory are genuinely different things — the program is static bytes, the process is that program plus the four-piece list above, actively changing as it runs.

The states a process moves through

• Running — currently executing on a CPU core.
• Blocked / waiting — can't proceed (e.g. waiting on disk I/O).
• Ready — runnable, waiting for the scheduler to pick it.

The 5-state model is the one to know for exams — it adds New (being created) and Terminated (finished) around the same core three:

stateDiagram-v2
    [*] --> New
    New --> Ready
    Ready --> Running
    Running --> Ready
    Running --> Waiting
    Waiting --> Ready
    Running --> Terminated
    Terminated --> [*]

GATE 2024: which transition is impossible — Running→Ready, Waiting→Running, Ready→Waiting, Running→Terminated? Answer: Waiting→Running and Ready→Waiting. A waiting process has no claim on the CPU yet — it must pass through Ready first, since only the scheduler decides who gets Running, and it only looks at the Ready queue. A Ready process was never given the CPU, so it has nothing to "wait for" yet. Rule: it's always Blocked → Ready → Running, never a shortcut past Ready in either direction.

GATE 2020 asks which transitions are possible under preemptive scheduling — same rule: Running→Ready (preemption), Ready→Running (dispatch), Blocked→Ready (I/O completes) are all fine; Blocked→Running directly is not.

Quick recall

• A process = PID + memory image (code/data/stack/heap) + execution context (PCB: PC, registers, SP, flags) + I/O state
• Program (static bytes on disk) ≠ process (that program + all four pieces, running)
• 5-state model: new → ready → running → terminated, with waiting branching off running
• Rule: always Blocked → Ready → Running, never a shortcut past Ready in either direction