🔄

Processes — Concept, Scheduling, Operations & IPC

How a passive program comes alive as a running process, how the OS juggles thousands of them, how processes are born and die, and how isolated processes still manage to talk to each other.

Process & PCB Scheduling fork & exec IPC

Press Next → or use ← → arrow keys

Section 01

What Is a Process? The Program Comes Alive

🍰 ANALOGY · THE RECIPE AND THE COOK

A printed recipe is passive — just instructions on paper, doing nothing on its own. A cook actively following that recipe has state: which step they're on, the ingredients in hand, the half-mixed bowl.

A program is the recipe (a file on disk). A process is the cook — a program in execution, with its own program counter, registers, stack and heap. The same recipe can bake ten cakes in ten kitchens: one program, many processes.

⚡

Program vs Process — Never Confuse Them

A program is a passive file of instructions. A process is that program in execution — an active entity the OS can pause and resume at the exact instruction it stopped on.

Section 01 · Diagram

The Memory Layout of a Process

💥

Heap and Stack Grow Toward Each Other

Text and data are fixed at load time. The heap grows one way and the stack the other, into the free space between them. If they ever collide, you get the classic stack overflow.

Section 02

The Five Process States

🚦

Only Legal Transitions Allowed

A process is admitted (New→Ready), dispatched (Ready→Running), and either times out (Running→Ready), blocks on I/O (Running→Waiting) or exits. A waiting process cannot jump straight to Running — it must pass back through Ready first. Only one process runs per core.

Section 03

The Process Control Block (PCB)

For every process the kernel keeps one struct — its identity card. Linux calls it task_struct; Windows calls it EPROCESS. On a context switch, everything needed to resume the process is saved here.

Field	What it holds
PID	Process ID (plus PPID, UID, GID)
State	New / Ready / Running / Waiting / Terminated
Program Counter	Address of the next instruction to run
Registers	RAX, RBX, RSP, RBP, flags — saved every switch
Memory info	Base/limit registers, page-table pointer
I/O status	Open file descriptors, devices, pending I/O
Accounting	CPU time, priority, scheduling parameters

🔎

See a Live PCB

On Linux, ps -ef lists every process's PID, PPID, state and CPU time, and cat /proc/<pid>/status shows a live snapshot of that task's task_struct through the /proc pseudo-filesystem.

Section 04

Process Scheduling — The Queues

🔁

Round and Round the Queues

The short-term scheduler dispatches a ready process to the CPU. When its time slice expires it returns to the ready queue; when it needs I/O it moves to a device queue and, once the I/O completes, rejoins the ready queue. Scheduling is what makes multiprogramming work.

Section 04 · Schedulers

The Three Schedulers

📥

Long-Term

job scheduler

Decides which jobs enter memory. Runs seconds-to-minutes apart. Controls the degree of multiprogramming — too many processes and thrashing begins.

⚡

Short-Term

CPU scheduler

Picks the next ready process and hands it the CPU. Runs every few milliseconds, so it must be blazing fast — its own cost is pure overhead. The scheduler's hot path.

💾

Medium-Term

the swapper

In swapping systems only. Temporarily swaps a process out to disk when memory is tight, then swaps it back later — lowering the degree of multiprogramming.

⚖️

Keep a Healthy Mix

CPU-bound processes (matrix multiply, video encode) run long bursts with little I/O; I/O-bound ones (editors, web servers) make short bursts between long waits. A good scheduler mixes both — all-CPU leaves the disk idle, all-I/O leaves the CPU idle.

Section 04 · Context Switch

Anatomy of a Context Switch

🔧 Five steps · pure overhead (1–1000 µs)

1

An interrupt or system call transfers control to the kernel.

2

Save process A's registers (PC, general-purpose, flags) into A's PCB.

3

The scheduler picks process B from the ready queue.

4

Load B's registers from its PCB and switch the page table.

5

Return to user mode — B resumes at its saved program counter.

Section 05

Operations on Processes — fork & exec

🧬

fork()

clone the process

Creates an exact copy of the caller. Now two processes run the same code from the line after fork. It returns twice: 0 in the child, the child's PID in the parent (<0 on error).

📼

exec()

become a new program

Replaces the current memory image with a different executable, keeping the same PID. This is how a shell runs a command: fork a child, then exec the program.

🪶

Copy-on-Write

why fork is cheap

Parent and child share the same physical pages, marked read-only. Only when one writes does the kernel copy that single page — so fork stays nearly free until they actually diverge.

Aspect	fork() alone	fork() + exec()
Child's code	same as parent	a brand-new program
PID	new (e.g. 4822)	new (e.g. 4822)
Result	two identical processes	parent + a different program

Section 05 · Tree

The Process Tree

🌳

One Parent Each, All the Way Up

Every process except init (PID 1) has exactly one parent, so processes form a tree. Run pstree to see yours. Kill a parent and its children usually become orphans — adopted and reaped by init.

Section 05 · Termination

How Processes End

Term	What happened	The fix
🧟 Zombie	Child exited but the parent never called `wait()`	Parent must `wait()` or handle SIGCHLD
👶 Orphan	Parent died before the child	`init` adopts & reaps it automatically
😈 Daemon	Deliberately orphaned to run in the background	Intentional — fork twice, become session leader

🚪 Four ways a process exits

Normal

exit(0) or returning from main() — signals success to the parent.

Error

exit(non-zero) — the parent inspects the code with WEXITSTATUS.

Signal

A fatal signal such as kill -9 (SIGKILL) — which cannot be caught.

Parent

The parent terminates its children — cascading when the parent itself dies.

Section 06

Inter-Process Communication (IPC)

🏢 ANALOGY · TWO LOCKED OFFICES

Two employees work in soundproof, locked offices but must collaborate. They have two options: slide notes under a shared door (fast, both see the same paper) — or pick up the office phone (slower, but works between buildings).

That is exactly IPC. Processes are isolated by design — one cannot read another's memory. The shared door is shared memory; the phone is message passing.

🤝

Why Cooperate At All?

Four reasons: information sharing (many users, one file), speedup (parallel workers), modularity (small trusted services), and convenience (editing, compiling and printing at once).

Section 06 · Diagram

Shared Memory vs Message Passing

Aspect	Shared Memory	Message Passing
Speed	Very fast — direct access	Slower — kernel copy each message
Setup	High — mmap, permissions	Low — `send()` / `recv()`
Sync	Manual — semaphores/mutexes	Built-in (send/receive blocks)
Best for	Large data, one machine	Small messages, distributed

Section 07

Producer–Consumer — The Classic Problem

📦 The bounded buffer

Producer

Generates items (e.g. print jobs) and places them into a shared buffer — but must wait if the buffer is full.

Consumer

Removes items and processes them — but must wait if the buffer is empty.

Indices

in points to the next free slot, out to the next full one; one slot is always left unused so "full" ≠ "empty".

⚠️

IPC Without Synchronisation Is a Bug Factory

With busy-wait loops on a real multiprocessor, reads and writes to in and out can interleave and corrupt data — a race condition. The fix is semaphores (covered in the synchronisation chapter). Never ship unguarded shared memory.

Section 08–09

The IPC Toolbox

🪈

Pipes

The oldest UNIX IPC — a one-way byte stream between related processes. Exactly what | does in the shell. Named pipes (FIFOs) persist on the filesystem.

📬

Message Queues

A kernel-maintained list of messages with msgsnd()/msgrcv(). Persist beyond the sender, support priorities.

🧠

Shared Memory

One region mapped into several processes at pointer speed — the fastest IPC. You must synchronise it yourself with semaphores.

🔌

Sockets

Endpoints for communication — the same API within one machine (UNIX sockets) or across the internet (TCP/UDP). The base of every client-server system.

🔔

Signals

Software interrupts — a simple notification (SIGUSR1, SIGKILL). No data payload, not queued: notifications, not messages.

📞

RPC

A function-call abstraction over the network: a stub marshals arguments, sends, and waits for the reply. The base of gRPC and friends.

Section 10–11

Blocking vs Non-Blocking · IPC in the Wild

Call	Synchronous (blocking)	Asynchronous (non-blocking)
`send()`	Blocks until the message is received	Returns immediately (queued)
`recv()`	Blocks until a message arrives	Returns at once with data or "would block"
Style	Simple — the caller waits	Concurrent — the caller polls or is notified

🌐

Chrome

Each tab is a separate process talking to the browser via named pipes — a crashed tab can't take down the whole browser.

🧵

Shell Pipeline

cat log | grep ERROR | wc -l — three processes, two pipes, each stage's stdout wired to the next stage's stdin.

🤖

Android Binder

Every app is an isolated process; all app ↔ service talk goes through Binder, a custom kernel message-passing IPC.

Section 12

Common Pitfalls

Pitfall	Symptom	Fix
Zombie explosion	Process table fills with defunct entries	Parent `wait()`s or handles SIGCHLD
Fork bomb	System freezes — recursive `fork()`	Set `ulimit -u`; never fork unbounded
Shared-memory race	Data corruption, random crashes	Guard with semaphores or mutexes
Deadlock in send()	Both processes wait forever	Non-blocking sends or timeouts
Pipe with no reader	Writer gets SIGPIPE and dies	Handle SIGPIPE or check `write()`
Lost signals	A signal fires while one is pending	Signals aren't queued — use signalfd / MQs

Section 13

Eight Ideas Worth Remembering

🔄 PROCESSES · SCHEDULING · IPC

1

A program is passive (bytes on disk); a process is active — a program in execution with its own PC, registers, stack, heap and PCB.

2

Every ready process waits in the ready queue, every blocked one in a device queue. Keep the short-term scheduler O(1) or O(log n).

3

Context switches are pure overhead — a full save + reload of the register set. Minimise them with a sensible time quantum.

4

fork() returns twice — 0 in the child, the child's PID in the parent. Always check the <0 error case first.

5

Never leave a zombie — the parent must wait() for every child or reap them via a SIGCHLD handler.

6

Shared memory is fastest but most dangerous — guard every shared write with a mutex or semaphore.

7

Prefer message passing for clarity and portability; prefer shared memory for raw throughput on one machine.

8

Signals are notifications, not messages — no reliable payload, not queued. For anything richer use message queues or sockets.

FINAL

From One Process to Thousands Cooperating

4Memory segments

5Process states

3Schedulers

2×fork() returns

2IPC models

6IPC mechanisms

🎯

You Can Now Follow a Process End to End

From a program coming alive, through its states, its PCB, the scheduler's queues and context switches, how it forks and dies, all the way to how isolated processes cooperate through IPC — you now have the full life story of a process.

📚

Where To Go Next

Dive into CPU scheduling algorithms (Round Robin, priority, CFS) and process synchronisation (semaphores, mutexes, the critical-section problem). Try ps -ef, pstree and strace to watch real processes at work.

🔄 End of tutorial · Press ← to review, or click Restart