Why Threads?

01 Introduction

Unit 3 developed the process as the fundamental unit of an operating system. A process owns an address space, a set of open files, credentials, and a machine state. This bundling is convenient for isolation: a bug in one process cannot corrupt another. But it is inconvenient for a different reason — everything inside a process runs as a single thread of control, one program counter, one stack, one instruction stream.

Consider what that means for the workloads modern systems actually run. A web server wants to handle many requests at once but share a common cache and log file. A video decoder wants to split frames across CPU cores but write into one output buffer. A spreadsheet wants to recalculate in the background while the user continues to edit. A build system wants to compile independent files in parallel while linking them into one executable. Each of these workloads wants many streams of execution that share the process's resources rather than duplicate them.

The abstraction that makes this possible is the thread: a unit of execution inside a process. Threads are conceptually a refinement of the process model — they split the "unit of resource ownership" from the "unit of execution". This lesson explains why that split is useful, what threads actually are, what they share and what they own, and what costs they impose. Lessons 4.2 through 4.5 then examine the implementation models, the multicore implications, and the POSIX programming interface.

02 Learning objectives

This lesson contributes to U4.1 and to course learning outcomes CLO2 and CLO8.

03 Required reading

• OSTEP — Chapter 26, Concurrency: An Introduction. Read the introduction for the motivation and the framing of concurrency as one of the three "easy pieces" of operating systems.
• Operating System Concepts — Chapter 4, Sections 4.1 and 4.2. The classical presentation of the thread concept, its benefits, and its relationship to the process.
• Love, R. — Linux Kernel Development, 3rd ed., Chapter 3, the section on threads. How Linux distinguishes threads from processes internally (the task_struct view).
• Linux man pages: man 7 pthreads (the POSIX threads overview), man 3 pthread_create, man 2 clone (the Linux-specific call that underlies both fork and thread creation).

04 Core content

4.1 The process revisited

In Lesson 3.1, the process was defined as "a program in execution". Implicitly, that definition bundles two separate concepts into a single abstraction:

• A unit of resource ownership. The process owns an address space, a set of open file descriptors, credentials, signal handlers, and other resources. These are granted by the kernel and are the process's "identity" from the OS's point of view.
• A unit of execution. The process has a program counter, a stack, a register set, and a stream of instructions that it executes. This is the "thread of control" through the program.

For a program with a single thread of control — a shell, a compiler, a command-line tool — this bundling is invisible. There is exactly one unit of execution inside the process and nothing is lost. The scheduler chooses between processes, context switches save and restore one register state, and the model from Unit 3 applies directly.

For a program that wants to do several things at once — a web server, a GUI application, a parallel computation — the bundling becomes restrictive. To get a second stream of execution, the program has to create a whole new process with its own address space, its own file descriptors, and its own copy of any state it needs to share. That is expensive, and it is inconvenient: the two processes cannot easily see each other's data, so any communication must go through pipes, shared memory, or some other mechanism the OS provides.

The thread abstraction is what happens when we relax the bundling: keep the process as the unit of resource ownership, but allow multiple units of execution to live inside it.

4.2 What a thread is

A thread is a sequence of instructions executing within a process. Every process has at least one thread; some systems allow many threads per process. All threads of a process share the process's address space, its open files, its signal handlers, and its credentials — that is, everything the process owns. Each thread has its own program counter, its own register set, its own stack, and its own thread ID.

The definition is best understood by contrasting it with the process from Unit 3. A process is a container: it holds memory, files, and identity. A thread is a stream of execution that runs inside that container. The container can be shared by several streams; the streams themselves are independent.

4.3 What threads share and what they own

The list of shared versus per-thread resources is the single most important thing to internalise about threads. It determines everything about how threads behave, what can go wrong, and what the operating system must do to manage them.

Two consequences of this table deserve emphasis.

• Shared memory means direct communication but also races. When thread A wants to pass data to thread B, it writes into the shared heap and B reads it. No pipe, no message, no kernel involvement. But the same property means that two threads writing to the same location at the same time is a hazard. Race conditions, locks, and synchronization — the subject of Unit 6 — exist precisely because threads share memory.
• Shared resources mean the kernel tracks fewer objects per thread. A thread does not have its own page table or its own credential set. The kernel's per-thread state is much smaller than its per-process state. This is one reason thread creation and switching are cheaper than process creation and switching.

4.4 The four classic benefits

The textbook literature identifies four benefits of threads over processes for the same workloads. Each corresponds to a specific cost that threads avoid.

4.5 The costs of threads

The benefits come at a price. Four costs appear repeatedly in practice, and understanding them is essential for using threads well.

Loss of isolation

Because threads share the address space, a bug in one thread can corrupt data that another thread depends on. A stray write to an out-of-bounds array index, a use-after-free of a shared pointer, a null dereference through a shared structure — all of these affect every thread in the process. In a multi-process design, the same bug would crash one process without affecting the others.

Synchronization burden

Every shared mutable resource must be protected, and every access must be checked. The programmer must reason about interleavings, choose appropriate primitives, and avoid the subtle bugs — race conditions, deadlocks, livelocks — that arise when concurrency is not managed carefully. This is the single largest source of complexity in multithreaded software, and it is the subject of Units 6 and 7.

Debugging difficulty

Bugs in concurrent code are notoriously difficult to reproduce. A race condition may manifest only one run in a million, only under specific loads, or only on specific hardware. A tool like GDB, which works by pausing and stepping through code, changes the timing that produced the bug in the first place, often making it disappear. This is why multithreaded code requires a different debugging discipline than single-threaded code.

Per-thread resource consumption

Each thread needs its own stack, which on Linux defaults to about 8 MB of virtual address space. A program that creates thousands of threads can consume tens of gigabytes of address space — a significant cost, even if the stacks are sparsely used in physical memory. Modern language runtimes that support very large numbers of concurrent tasks (Go, Erlang) use much smaller stacks and grow them dynamically, precisely to avoid this cost.

4.6 When a process is the better choice

Threads are not always the right answer. There are three contexts in which a process-based design is preferable.

1. When isolation matters more than sharing. If a task must not corrupt another task's data — because the tasks are untrusted, or because the consequences of corruption are severe — a process boundary provides containment that threads cannot. Chrome's site-isolation model, in which each tab is a separate process, is a deliberate choice of isolation over the economy of threads.
2. When the tasks do not share state. If two tasks operate on disjoint data and communicate only through well-defined messages, the sharing advantage of threads disappears. In that case, processes provide equivalent performance with stronger isolation.
3. When the workload is I/O-bound and the OS provides a scalable alternative. Event-driven architectures with non-blocking I/O can handle tens of thousands of concurrent connections on a single thread, without the memory cost or synchronization burden of one thread per connection. This is the design used by Nginx, Node.js, and many modern network servers.

In practice, modern systems use a hybrid: a small pool of worker processes, each running a small pool of threads. The processes provide coarse isolation; the threads provide parallelism and resource sharing within each process. This pattern appears in PostgreSQL (process per connection), Apache prefork (process per connection), Apache worker (thread per connection), and most production web servers.

4.7 A concrete comparison: two server designs

To make the trade-offs concrete, compare two ways to build a simple web server.

Neither design is universally better. The process model is safer and simpler to reason about; the thread model is faster and more natural when sharing is the point. Modern high-performance servers often use a hybrid — process-based isolation with thread-based workers inside each process — because each model contributes what it does best.

4.8 Threads and the Unit 3 model

It is worth pausing to see how threads fit into the process model from Unit 3. Three relationships matter.

• A thread is not a process. The five-state model from Lesson 3.2 describes states of a thread of control, not of a process. When we said "the process is running", we meant "one of its threads is running". Once we introduce threads, the process's state is not a single value — it is the collection of its threads' states.
• The kernel tracks both. A process is the unit of resource ownership: the kernel holds a page table, a file descriptor table, and credentials for the process as a whole. A thread is the unit of scheduling: the kernel holds a program counter, a register set, and a kernel stack for each thread. On Linux, both are represented by the same underlying task_struct, which is why threads and processes look similar at the kernel level — but the resource-sharing semantics differ.
• Context switches between threads are cheaper. This was foreshadowed in Lesson 3.5. Because threads share the memory map, a thread switch does not need to change the page-table base, flush the TLB, or invalidate the cache. Only the registers and stack pointer change. This is one of the main performance arguments for threads over processes, and it becomes concrete in Lesson 4.5.

4.9 Preview: the threading models

Once a process can contain multiple threads, the next question is where the thread abstraction is implemented. Two broad answers exist, and they lead to the different models examined in Lessons 4.2 and 4.3.

• User-level threads. The thread library runs entirely in user space; the kernel sees only one thread of control per process. Switching between user threads does not involve the kernel, so it is very fast. But a blocking system call in any user thread blocks the entire process, and user threads of one process cannot run on multiple cores.
• Kernel-level threads. The kernel knows about each thread and schedules them independently. Blocking calls block only the calling thread; threads can run on multiple cores. The cost is that thread operations require kernel involvement, making them slower than pure user-thread operations.

Modern general-purpose systems — including Linux and Windows — use the kernel-level model, because it solves both the blocking and multicore problems and the performance penalty is modest. User-level threads survive in specialised contexts and as a research model, and their ideas influence modern lightweight concurrency approaches such as Go's goroutines.

05 Worked example

To make the concepts concrete, look at the same task implemented two ways: once with processes and once with threads.

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

#define N      40000000L
#define WORKERS 4

long *data;    /* in shared memory */
long *result;  /* one slot per worker */

int main(void) {
    data   = mmap(NULL, N * sizeof(long), PROT_READ | PROT_WRITE,
                  MAP_SHARED | MAP_ANONYMOUS, -1, 0);
    result = mmap(NULL, WORKERS * sizeof(long), PROT_READ | PROT_WRITE,
                  MAP_SHARED | MAP_ANONYMOUS, -1, 0);

    for (long i = 0; i < N; i++) data[i] = 1;

    size_t per = N / WORKERS;

    for (int w = 0; w < WORKERS; w++) {
        pid_t pid = fork();
        if (pid == 0) {
            /* Child: sum its chunk */
            long sum = 0;
            for (size_t i = w * per; i < (w + 1) * per; i++) sum += data[i];
            result[w] = sum;
            _exit(0);
        }
    }
    for (int w = 0; w < WORKERS; w++) wait(NULL);

    long total = 0;
    for (int w = 0; w < WORKERS; w++) total += result[w];
    printf("total = %ld\n", total);
    return 0;
}

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

#define N      40000000L
#define WORKERS 4

long  data[N];
long  result[WORKERS];
size_t per = N / WORKERS;

void *worker(void *arg) {
    int w = *(int *)arg;
    long sum = 0;
    for (size_t i = w * per; i < (w + 1) * per; i++) sum += data[i];
    result[w] = sum;
    return NULL;
}

int main(void) {
    for (long i = 0; i < N; i++) data[i] = 1;

    pthread_t t[WORKERS];
    int ids[WORKERS];
    for (int w = 0; w < WORKERS; w++) {
        ids[w] = w;
        pthread_create(&t[w], NULL, worker, &ids[w]);
    }
    for (int w = 0; w < WORKERS; w++) pthread_join(t[w], NULL);

    long total = 0;
    for (int w = 0; w < WORKERS; w++) total += result[w];
    printf("total = %ld\n", total);
    return 0;
}

gcc -Wall -Wextra -g -O2 -pthread -o sum-threads sum-threads.c
gcc -Wall -Wextra -g -O2 -o sum-procs sum-procs.c

$ time ./sum-procs
total = 40000000
real    0m0.42s

$ time ./sum-threads
total = 40000000
real    0m0.31s

06 Interactive activity

07 Knowledge check

08 Unit discussion

09 Practice exercise

10 Summary

• A thread is a unit of execution inside a process. Every process has at least one thread; some have many.
• Threads share the code, data, heap, open file descriptors, signal handlers, and credentials of the process. Each thread owns its program counter, register set, stack, thread ID, and thread-local storage.
• The four classic benefits of threads: responsiveness (a background task does not freeze the main thread), resource sharing (threads share memory directly), economy (creating and switching threads is cheaper than for processes), and scalability (threads run in parallel on multicore systems).
• The four classic costs of threads: loss of isolation (a bug in one thread affects all), synchronization burden (every shared access must be protected), debugging difficulty (race conditions are non-deterministic and often disappear under debuggers), and per-thread resource consumption (each thread needs its own stack, often 8 MB of virtual address space by default).
• Threads are not always the right answer. When isolation matters more than sharing, when the tasks do not share state, or when an event-driven design would fit better, a process-based or asynchronous design may be preferable. Modern systems often combine both: worker processes, each containing a small pool of threads.
• On Linux, both processes and threads are represented by the same underlying task_struct. A process is a group of threads that share an address space, file descriptor table, and credentials.

11 References

• Arpaci-Dusseau, R. H., & Arpaci-Dusseau, A. C. Operating Systems: Three Easy Pieces, Chapter 26. Available online at ostep.org.
• Silberschatz, A., Galvin, P. B., & Gagne, G. Operating System Concepts, 10th ed., Chapter 4, Sections 4.1–4.2.
• Love, R. Linux Kernel Development, 3rd ed., Chapter 3 (Process Management), the section on threads. Addison-Wesley, 2010.
• Linux man-pages: man 7 pthreads, man 3 pthread_create, man 2 clone, man 5 proc (the /proc/<pid>/task/ directory).
• Butenhof, D. R. Programming with POSIX Threads, Chapter 1. Addison-Wesley, 1997. (The classical introduction to the thread model from the programmer's perspective.)