⚙️ Module 02: Process Management & IPC

Focus: Process Anatomy, PCB & TCB, Multiprogramming vs Multitasking vs Multiprocessing vs Multithreading, Context Switching, fork() & Copy-On-Write, Zombie/Orphan processes, and Inter-Process Communication (IPC).

📑 Table of Contents

1. Process Concept & Memory Layout
2. Process Control Block (PCB)
3. Process Lifecycle: 5-State & 7-State Models
4. Multiprogramming vs Multitasking vs Multiprocessing vs Multithreading
5. Process vs Thread: Deep Dive
6. Threading Models (1:1, N:1, M:N) & Green Threads
7. Context Switching Internals
8. Process Creation & Lifecycle (fork, COW, exec, wait)
9. Zombie and Orphan Processes
10. Inter-Process Communication (IPC) Mechanisms
11. Common Mistakes & Gotchas
12. Practice Problems with Solutions
13. High-Yield Interview Questions & Answers

1. Process Concept & Memory Layout

A Process is a program in active execution. While a program is a passive entity sitting on a disk (executable file like a.out or .exe), a process is an active entity loaded into RAM with allocated hardware resources.

Memory Segments Breakdown:

1. Text (Code) Segment: Read-only region containing executable binary instructions. Shared among multiple instances of the same program (e.g., two terminal windows running bash).
2. Data Segment: Stores initialized global and static variables (e.g., static int count = 100;).
3. BSS Segment (Block Started by Symbol): Stores uninitialized global and static variables (e.g., int global_array[1000];). Takes $0$ bytes in the executable file on disk because the kernel zeros it out at runtime.
4. Heap Segment: Dynamically allocated memory at runtime via malloc(), calloc(), or new. Managed by the programmer / language runtime.
5. Stack Segment: Automatically manages function call frames, local variables, parameters, and return addresses. Follows LIFO (Last-In-First-Out).

2. Process Control Block (PCB)

The Process Control Block (PCB) (called struct task_struct in the Linux kernel) is the central data structure the OS kernel uses to represent and track a process.

3. Process Lifecycle: 5-State & 7-State Models

The Classic 5-State Process Model

1. New: The process is being created (memory allocated, PCB initialized).
2. Ready: The process is loaded in RAM and waiting to be assigned a CPU core by the scheduler.
3. Running: The process's instructions are actively being executed on a CPU core.
4. Waiting (Blocked): The process cannot run because it is waiting for an external event (disk I/O, network packet, lock acquisition, timer sleep).
5. Terminated: The process has finished execution; resources are released, but PCB may remain until reaped by parent.

The 7-State Model (With Memory Swapping)

When physical RAM runs low, the OS moves inactive processes from RAM to the swap space on disk:

• Ready Suspended: Process is ready to execute, but its address space has been swapped to disk.
• Blocked Suspended: Process is waiting for an I/O event AND has been swapped to disk.

4. Multiprogramming vs Multitasking vs Multiprocessing vs Multithreading

These four terms are frequently tested in interviews and often confused:

Comparison Matrix

5. Process vs Thread: Deep Dive

A Thread is the smallest unit of execution that the OS scheduler can dispatch. It is often called a Lightweight Process (LWP).

What is Shared vs Private?

Why Threads are "Lighter" than Processes:

1. Creation Overhead: Spawning a thread doesn't require duplicating page tables or address spaces.
2. Context Switch Speed: Switching between threads of the same process keeps the same page table (%CR3), meaning the TLB (Translation Lookaside Buffer) is NOT flushed and CPU caches remain warm.
3. Communication: Threads share memory directly (no syscalls needed for IPC), whereas processes require pipes, sockets, or shared memory syscalls.

6. Threading Models (1:1, N:1, M:N) & Green Threads

1. 1:1 Model (Kernel-Level Threads - NPTL on Linux):
   • Every user thread maps directly to an OS kernel thread.
   • Advantage: True multicore parallelism. If Thread 1 blocks on disk I/O, Thread 2 runs unaffected on another core.
   • Cost: Thread creation and context switches require kernel traps.
2. N:1 Model (User-Level Threads / Green Threads):
   • Multiple user threads mapped to a single kernel thread via a user-space library.
   • Advantage: Ultra-fast creation and switching (no syscalls).
   • Fatal Flaw: If ONE user thread issues a blocking I/O syscall, the entire process blocks. Cannot use multiple CPU cores.
3. M:N Model (Two-Tier / Go Goroutines / Java Project Loom):
   • Multiplexes $M$ lightweight user routines onto $N$ kernel OS threads.
   • Combines instant context switches with multicore scalability and non-blocking I/O multiplexers (epoll).

7. Context Switching Internals

A Context Switch is the procedure by which the CPU saves the state of the currently executing process/thread and restores the state of another ready process/thread.

Step-by-Step Breakdown of a Process Context Switch:

1. Interrupt Trigger: Hardware timer expires (preemption) or process makes a blocking I/O system call.
2. Save CPU Context: Hardware & OS push all general-purpose registers (RAX, RBX, RSI, RSP, RIP, EFLAGS) onto the process's Kernel Stack.
3. Update PCB: State of $P_0$ is changed from RUNNING to READY or WAITING.
4. Run Scheduler: The CPU scheduling algorithm selects next candidate process ($P_1$).
5. Switch Address Space: The OS updates the CPU's %CR3 register to point to $P_1$'s Page Table base. This causes a TLB Flush.
6. Restore CPU Context: Load registers from $P_1$'s PCB / Kernel Stack into hardware registers.
7. Resume Execution: Execute return instruction (sysret / iret), setting the Program Counter to $P_1$'s saved %RIP.

The Hidden Cost: Direct vs Indirect Overhead

• Direct Overhead: ~1–5 microseconds spent executing kernel context switch instructions and updating memory pointers.
• Indirect Overhead (Cache Pollution): When $P_1$ begins running, CPU L1/L2/L3 caches and the TLB are filled with data from $P_0$. $P_1$ experiences a barrage of cache misses and TLB misses for several milliseconds until its working set is warm.

8. Process Creation & Lifecycle (fork, COW, exec, wait)

1. The fork() System Call

In Unix-like systems, new processes are created by cloning an existing process using fork():

2. Copy-On-Write (COW)

Historically, fork() duplicated the entire physical RAM of the parent process, which was devastatingly slow. Modern OSes use Copy-On-Write (COW):

3. exec() Family

Replaces the current process's text, data, heap, and stack segments with a completely new binary from disk (e.g., execvp("ls", args)). The PID does NOT change.

4. wait() / waitpid()

Suspends the parent process until one of its children terminates, collecting the child's exit status code and allowing the kernel to free the child's PCB.

9. Zombie and Orphan Processes

Reaping Zombies in C (The SIGCHLD Signal Handler):

10. Inter-Process Communication (IPC) Mechanisms

Because processes run in strictly isolated address spaces, they cannot directly read or write each other's memory. The OS provides IPC mechanisms:

Comparison of IPC Mechanisms

1. Anonymous Pipe Code Example

11. Common Mistakes & Gotchas

[!CAUTION]

1. Fork Bombs and Uncontrolled Recursion

Calling fork() in a loop without proper termination (while(1) fork();) will exponentially spawn $2^N$ processes, instantly crashing the system by exhausting the process table and RAM.

[!WARNING]

2. Forgetting to Close Pipe Ends

If the parent process does not close its unused write-end of a pipe (close(fd[1])), a child reading from fd[0] will hang forever, because read() only returns EOF (0 bytes) when ALL write descriptors across the entire system are closed!

[!NOTE]

3. Confusing Thread Stacks with Heap

Thread stacks are isolated (each thread has its own %RSP), but because threads share a single address space, a thread can technically write to another thread's stack if it obtains a raw pointer to it. This leads to silent memory corruption bugs.

12. Practice Problems with Solutions

Problem 1: fork() Execution Counting

Question: How many times will the string "Hello" be printed by the following code?

Solution:

• Initial state: $1$ process ($P_0$).
• 1st fork(): Creates $1$ child $\rightarrow$ Total = $2$ processes.
• 2nd fork(): Both processes fork $\rightarrow$ Total = $4$ processes.
• 3rd fork(): All $4$ processes fork $\rightarrow$ Total = $8$ processes ($2^3$).
• Each of the $8$ concurrent processes reaches printf("Hello\n").
• Answer: "Hello" is printed 8 times.
• General Formula: For $n$ consecutive fork() calls, total processes created $= 2^n$. Number of child processes $= 2^n - 1$.

Problem 2: Process State Identification

Question: Trace the process state transitions for the following scenario:

1. Process is launched from terminal.
2. Process calls read(fd, buffer, 1024) from a hard drive file.
3. Disk controller completes data read into RAM buffer.
4. Process time slice expires during loop computation.
5. Process finishes execution.

Solution:

1. $\text{NEW} \rightarrow \text{READY}$ (Admitted to memory).
2. $\text{READY} \rightarrow \text{RUNNING} \rightarrow \text{WAITING / BLOCKED}$ (Voluntarily yields CPU waiting for disk I/O).
3. $\text{WAITING} \rightarrow \text{READY}$ (Disk interrupt fires, ISR marks process ready in scheduler queue).
4. $\text{READY} \rightarrow \text{RUNNING} \rightarrow \text{READY}$ (Preempted by timer interrupt; moved to ready queue).
5. $\text{RUNNING} \rightarrow \text{TERMINATED}$ (Calls exit()).

13. High-Yield Interview Questions & Answers

Q1: What happens during a fork() call under Copy-On-Write (COW)?

Answer:

1. The kernel allocates a new PCB (task_struct) and assigns a unique PID to the child.
2. The kernel copies the parent's page table entries to the child rather than duplicating physical memory pages.
3. Both parent and child page table entries are marked as Read-Only.
4. If either process attempts to modify a page, a hardware page fault exception is raised.
5. The kernel handles the page fault by allocating a new physical page frame, copying the original data, and mapping the newly allocated page with write permissions to the modifying process.

Q2: What is the difference between a Zombie process and an Orphan process? Which one is dangerous and why?

Answer:

• A Zombie has completed execution, but its parent has not yet invoked wait(). Its memory is freed, but its PCB slot and PID remain allocated in the kernel.
• An Orphan is still executing, but its original parent has died. It is automatically adopted by PID 1 (systemd/init).
• Danger: Zombies are dangerous if leaked in large quantities because the OS has a finite PID capacity (pid_max). If the PID table is exhausted, the OS cannot spawn any new processes, halting system daemons and new incoming user requests.

Q3: Why is Context Switching between Threads faster than between Processes?

Answer:

1. No Memory Space Switch: Threads of the same process share the same virtual address space. The CPU does not need to reload the page table base register (%CR3).
2. TLB Preservation: Because %CR3 is not changed, the Translation Lookaside Buffer (TLB) is not flushed, preserving cached virtual-to-physical address translations.
3. CPU Cache Warmth: L1/L2 data and instruction caches remain valid for the next thread if it accesses common process heap and text segments.

Q4: What are the primary IPC mechanisms in Linux, and which is the fastest?

Answer: The primary mechanisms are Anonymous Pipes, Named Pipes (FIFOs), Message Queues, Unix Domain Sockets, Network Sockets, and Shared Memory.
Shared Memory (shm_open/mmap) is the fastest because once the memory region is mapped into the virtual address spaces of both processes, data reads and writes occur directly via CPU memory bus instructions without crossing into kernel mode or performing buffer copies.

Q5: If a multi-threaded process calls fork(), what gets copied into the child process?

Answer: Under standard POSIX semantics, fork() in a multi-threaded program copies the address space, but only the single thread that invoked fork() is duplicated in the child. All other threads vanish. This is extremely hazardous if another thread was holding a mutex lock at the moment of fork(), because that lock will remain permanently locked in the child process without an owner, causing immediate deadlocks! For this reason, fork() in multi-threaded programs should almost always be immediately followed by exec().

Proceed to Module 03: CPU Scheduling Algorithms!