Processes & Threads — Programs Come Alive

What you'll learn

• The difference between a program and a process
• What the OS remembers about every process (its PCB) and the five states a process moves through
• How fork, exec and wait create and clean up processes
• What threads are, what they share, and what they keep private
• How to read a ps-style process table and spot zombies

By the end you will have written a real fork/wait program in C and a process-state simulator.

A recipe is not a meal 🍳

A program is a recipe: instructions sitting in a book (a file on disk). Nothing happens until somebody actually cooks.

A process is a cook who is cooking right now. The cook has a private kitchen: their own counter space, their own ingredients, and a bookmark showing which step of the recipe they are on. Run the same recipe twice and you get two cooks in two separate kitchens, each unaware of the other.

The operating system is the restaurant manager. It has only a few stoves (CPU cores) and many cooks, so it decides who gets a stove and for how long. To do that it keeps a clipboard for every cook.

What a process owns

• An address space: its private view of memory, split into the code (text), data (globals), heap (memory you malloc) and stack (function calls and local variables)
• CPU context: the registers and the program counter, the "bookmark" in the recipe
• Resources: open files, sockets, the current directory, the user it runs as

The kernel stores this bookkeeping in a process control block (PCB), which also holds the PID (process id), the parent PID, the state and scheduling information. Every process has a parent: on Linux the first process (PID 1, usually systemd) starts everyone else.

The life of a process

A process is not always running. At any moment it is in one of these states:

              admit             dispatch
   NEW ───────────────▶ READY ───────────────▶ RUNNING ────exit────▶ TERMINATED
                          ▲  ◀──────preempt───────┘  │
                          │                          │ block (wait for I/O)
                          │ wake (I/O finished)      ▼
                          └─────────────────────── WAITING

• NEW: being created
• READY: could run, waiting for a CPU
• RUNNING: executing on a CPU right now (at most one per core)
• WAITING (also called blocked): cannot continue until something happens, such as a disk read finishing or a key being pressed
• TERMINATED: finished, waiting to be cleaned up

Notice what is not allowed: a WAITING process never jumps straight to RUNNING. When its I/O finishes it becomes READY and must queue for the CPU again. Switching the CPU from one process to another is called a context switch: the kernel saves the old process's registers into its PCB and loads the new one's.

Creating processes: fork, exec, wait

On Unix-like systems a new process is born by cloning. fork() creates a child that is a copy of the caller: same code, same variables, same open files. The magic is that fork returns twice, once in each process:

• in the parent it returns the child's PID (a positive number)
• in the child it returns 0
• on failure it returns -1 and no child exists

#include <stdio.h>
#include <stdlib.h>
#include <sys/wait.h>
#include <unistd.h>

int main(void) {
    pid_t pid = fork();
    if (pid == 0) {
        printf("child: hello\n");
        exit(7);                      /* child finishes with status 7 */
    }
    int status;
    waitpid(pid, &status, 0);         /* parent sleeps until the child ends */
    printf("child exited with %d\n", WEXITSTATUS(status));
    return 0;
}

Three calls form the Unix process toolkit:

• fork() clones the current process
• exec() (a family: execl, execvp, ...) replaces the current process's code with a different program. The PID stays the same. A shell runs ls by doing fork and then exec("ls") in the child
• wait() / waitpid() lets a parent collect a child's exit status

Zombies and orphans

When a child exits, the kernel keeps a tiny record (its PID and exit status) until the parent calls wait. A child in that "dead but not yet collected" state is a zombie (Z in ps). It uses no CPU, and you cannot kill it, because it is already dead; the fix is for the parent to wait (or for the parent to exit, after which PID 1 adopts and reaps the zombie). An orphan is the opposite case: a child whose parent exited first. It is simply adopted by PID 1 and keeps running.

Careful: buffered output and fork

When stdout is a pipe or file, C's printf collects text in a buffer and writes it later. fork copies that unwritten buffer too, so the child can print the parent's old lines a second time when it exits. Call fflush(stdout) before fork. You will meet this bug in the first lab.

Threads: many hands, one kitchen

Back in the kitchen: instead of hiring a second cook with a whole new kitchen, what if two cooks share one kitchen? They share the counter and ingredients, but each follows their own step of the recipe. That is a thread.

A process can contain several threads. They run in the same address space:

• Shared: code, global variables, the heap, open files
• Private to each thread: its own stack, its own registers and program counter, its own thread id

#include <pthread.h>
#include <stdio.h>

void *work(void *arg) {
    printf("hello from thread %d\n", *(int *)arg);
    return NULL;
}

int main(void) {
    pthread_t t;
    int id = 1;
    pthread_create(&t, NULL, work, &id);  /* start a thread */
    pthread_join(t, NULL);                /* wait for it, like wait() for processes */
    return 0;
}

Processes vs threads

• Creating and switching between threads is cheaper: no new address space is needed
• Communicating is easy for threads (just read and write shared memory) but needs great care: two threads changing the same variable at the same time cause a race condition. Processes must use explicit tools such as pipes or shared-memory segments
• Isolation is weaker with threads: a crash (say, a bad pointer) in one thread takes down the whole process, while a crashed process leaves its siblings alone

Real programs mix both: a web browser typically uses one process per tab (isolation) and many threads inside each (speed). The next topics, scheduling and synchronization, build on this picture.

Reading the process table

On Linux, ps lists processes. A typical listing has columns for the PID, the PPID (parent PID), the STAT (state) and the command:

  PID  PPID STAT COMMAND
    1     0 Ss   systemd
  801     1 Ssl  dockerd
  955   801 Z+   worker
 1300     1 R+   ps

The first letter of STAT is the state:

• R: running or ready (on the run queue)
• S: sleeping, waiting for an event (interruptible: a signal can wake it)
• D: uninterruptible sleep, usually waiting for disk or other hardware I/O. It cannot be interrupted, which is why a stuck D process can resist even kill -9
• T: stopped (for example with Ctrl+Z)
• Z: zombie, finished but not yet reaped by its parent
• I: idle kernel thread

Extra characters after the letter add detail (s = session leader, l = multi-threaded, + = in the foreground). Process 955 above is a zombie whose parent is 801: the fix belongs in the parent (801 must wait for its children), not in a kill of 955.

Next you will write a shell pipeline that summarises such a table, the kind of one-liner every sysadmin writes.

Summary

• A program is a file; a process is a running program with its own address space, CPU context and resources, tracked by the kernel in a PCB
• States: NEW, READY, RUNNING, WAITING, TERMINATED. A blocked process returns to READY, never straight to RUNNING
• fork clones (returns 0 in the child), exec replaces the program, wait collects the exit status. An uncollected child is a zombie
• Threads share the heap, globals and files but keep their own stack and registers: cheaper and easier to share data, but with races and weaker isolation
• You wrote a fork/wait program, a lifecycle checker and a ps summary pipeline

Practice: read man 2 fork and man 2 waitpid, then try ps -eo pid,ppid,stat,comm | head on a Linux machine. Next: CPU scheduling, how the OS picks which READY process gets the CPU.