Processes and Threads: What They Are, Where They Came From and How They Work

What Is an Operating System? introduced processes and threads in a few paragraphs, and What Is a Processor? showed the hardware they run on. This article gives them the space they deserve. Almost every question about how a program behaves when it does more than one thing at a time, from “why did my server run out of memory?” to “why does this counter come out wrong?”, comes down to the difference between a process and a thread.

What they are

A process is a running program together with everything it owns: a private address space, open files and network connections, and an identity. A thread is one sequence of execution inside a process: a program counter, a set of registers and a stack. Every process has at least one thread; a multithreaded process has several, all sharing the process’s memory and resources.

The distinction is between ownership and execution. The process is the container that the operating system protects and accounts for; the thread is what the scheduler actually puts on a CPU core.

Why have both

One thread per process was the original model, and it is still the simplest: each process is isolated, and nothing inside it happens at the same time as anything else. Threads were added because many programs want to do several things at once on the same data:

• Use several cores. A single thread can run on only one core at a time. A computation split across threads can use them all.
• Stay responsive. An editor can keep accepting keystrokes in one thread while another saves the file or checks spelling.
• Overlap waiting. A server can wait on one client’s slow network connection in one thread while others serve everyone else.
• Share cheaply. Threads exchange data simply by reading and writing the same memory, with no copying through the operating system.

The cost of that sharing is the subject of half this article: when several threads can touch the same data, the programmer has to coordinate them.

Related words

A history of processes and threads

The 1960s: the process is named

The idea of a process grew out of multiprogramming and time-sharing. Once a computer switched between several programs, its designers needed a name for “a program as it is being run”, distinct from the program text and from the processor running it. Jack Dennis and Earl Van Horn gave the classic definition in 1966: a process is a locus of control within an instruction sequence, the abstract entity that moves through a program’s instructions as a processor executes them.¹ In the same years, Melvin Conway proposed the fork and join operations for splitting a computation into parallel paths and waiting for them to finish,² and Edsger Dijkstra’s Cooperating Sequential Processes introduced semaphores to coordinate processes that share data.³

Unix: fork, exec and the pipe

Unix (1969 onwards) made processes cheap and composable. A process is created with fork, which duplicates the caller, and given a new program with exec; the shell, pipes and redirection are all built from those two calls.⁴ Dennis Ritchie later noted that the split between fork and exec was not new: it was already present in the Berkeley time-sharing system of Project Genie, which Ken Thompson knew well.⁵ Each Unix process had exactly one thread of control, and for most of the 1970s that was the normal model.

The 1980s and early 1990s: threads arrive

As shared-memory multiprocessors appeared, a process with one thread became too coarse. Several systems split the process in two. Mach (Carnegie Mellon, from 1985) separated the task, which owns an address space and resources, from the thread, the unit of execution, and allowed many threads per task.⁶ Windows NT (1993) was designed from the start with processes that contain one or more kernel-scheduled threads.⁷⁸ Sun’s Solaris 2 used a two-level design that multiplexed user threads over kernel “lightweight processes”; from Solaris 9 (2002) every thread got its own lightweight process.⁹¹⁰

Researchers argued over where threads should live. User-level thread libraries were fast but invisible to the kernel, so one thread blocking in a system call stopped them all; kernel threads were safe but slower to create and switch. Anderson and colleagues proposed scheduler activations (1991) as a way for the kernel and a user-level library to cooperate.¹¹ The portable programming interface was settled in 1995 by POSIX threads (Pthreads, IEEE Std 1003.1c).¹²

Linux: one structure for both

Linux took an unusual route. Instead of separate process and thread objects, it has one kernel structure, the task, and a system call, clone, that creates a new task and lets the caller choose what to share with it: memory, open files, signal handlers and so on.¹³ Share nothing and you have a new process; share everything and you have a new thread. The first Pthreads library built on this, LinuxThreads (1996), had awkward corners, such as each thread showing up with its own process ID.¹⁴ The Native POSIX Thread Library (NPTL), written by Ulrich Drepper and Ingo Molnar, fixed them. It became part of glibc from version 2.3.2 and relies on support added in the Linux 2.6 kernel (2003) for thread groups and for fast user-space locks called futexes.¹⁵¹⁶¹⁴

Threads under criticism, and events

Threads made concurrency easy to start and hard to get right. In 1996 John Ousterhout gave a widely cited talk arguing that threads were a bad idea for most purposes and that event-driven programming was simpler.¹⁷ In 1999 Dan Kegel’s The C10K problem asked how one server could handle ten thousand simultaneous connections, when a thread per connection meant ten thousand stacks.¹⁸ The answer that spread was the event loop: one thread waiting on many connections through epoll or kqueue, as in nginx and later Node.js.¹⁹²⁰ In 2006 Edward Lee argued that threads were a fundamentally flawed model of concurrency because they make every shared variable a potential bug.²¹ Others had already defended them, arguing that the problems were in particular implementations, not the model.²²

Meanwhile the hardware turned against single threads. Once clock speeds stalled in the mid-2000s, more performance meant more cores, and more cores meant more threads. Languages also had to define precisely what a thread sees when another writes to memory: Java’s memory model was revised in 2004, and C and C++ gained one in 2011.²³²⁴²⁵

Lightweight threads return

The latest turn reconciles the two camps. Erlang (from 1986) had always run huge numbers of tiny, isolated processes inside one operating system process, scheduled by its runtime.²⁶ Go (2009) made goroutines the everyday unit of concurrency: cheap enough to start hundreds of thousands, and multiplexed by the Go runtime over a small set of OS threads.²⁷²⁸ Java added virtual threads in Java 21 (2023), which let ordinary blocking code scale like an event loop.²⁹ Many languages took a third path with async/await, which writes event-loop code in a sequential style.

A timeline at a glance

Models

The process life cycle

The kernel tracks what each process (or, on Linux, each task) is doing. On Linux, ps shows it as a one-letter state:³⁰

On Unix-like systems processes form a tree. Every process except the first has a parent, the process that created it, and each is identified by a process ID (PID).

1. Creation. fork creates a child that is a copy of the parent: same program, same memory contents, same open files. Copying is lazy: parent and child share every page copy-on-write, so only pages one of them modifies are actually copied.³¹
2. New program. The child calls execve, which replaces its whole address space with a new program while keeping its PID and, unless marked otherwise, its open files. This is how a shell connects the child’s standard input and output to a file or a pipe before the new program starts.
3. Termination. The child calls exit (or is killed by a signal). The kernel frees its memory but keeps a small record, its exit status, so the parent can learn how it ended. Until then it is a zombie.
4. Reaping. The parent calls wait or waitpid, collects the status, and the zombie disappears. If the parent dies first, the orphan is adopted by init (process 1) or a designated “subreaper”, which reaps it.³²

Here is the shell pipeline ls | wc -l built by hand from these calls:

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

/* The equivalent of the shell pipeline  ls | wc -l  */
int main(void) {
    int fd[2];
    pipe(fd);                          /* fd[0] is the read end, fd[1] the write end */

    if (fork() == 0) {                 /* first child: ls */
        dup2(fd[1], STDOUT_FILENO);    /* its output goes into the pipe */
        close(fd[0]); close(fd[1]);
        execlp("ls", "ls", (char *)NULL);
        _exit(127);                    /* reached only if exec failed */
    }
    if (fork() == 0) {                 /* second child: wc -l */
        dup2(fd[0], STDIN_FILENO);     /* its input comes from the pipe */
        close(fd[0]); close(fd[1]);
        execlp("wc", "wc", "-l", (char *)NULL);
        _exit(127);
    }
    close(fd[0]); close(fd[1]);        /* the parent uses neither end */
    while (wait(NULL) > 0)             /* reap both children */
        ;
    return 0;
}

Not every system works this way. The Win32 API has no fork: Windows creates a process and loads its program in one step with CreateProcess.³³ POSIX offers posix_spawn for the same one-step pattern, and some researchers argue that fork has become a liability: it is slow for large processes, interacts badly with threads, and complicates the kernel.³⁴

Threading models

There are three ways to map the threads a program creates onto the threads the kernel schedules:

General-purpose operating systems have converged on 1:1 for their native threads, and M:N now lives in language runtimes, which know enough about the program to schedule it well.

Communicating between processes

Because processes do not share memory by default, the operating system provides inter-process communication (IPC):

Shared memory is the fastest, and it brings back exactly the coordination problems of threads.

How they work

What the kernel stores

For every process, the kernel keeps a process control block; for every thread, its saved registers and scheduling state. In Linux both are the same task_struct, and threads of one process are simply tasks that share their memory map, file table and signal handlers and belong to one thread group. What user space calls a process ID is the thread group ID; each thread also has its own thread ID.¹³ You can see this from the shell:

ps -eLf               # one line per thread: LWP is the thread ID, NLWP the thread count
ls /proc/self/task    # each thread of a process has its own directory

Each thread needs its own stack, and stacks are where much of a thread’s cost lies. On Linux a new Pthread’s stack defaults to the process’s stack size limit, commonly 8 MiB of reserved address space;³⁷ on Windows the default is 1 MB.³⁸ Memory is committed only as the stack is actually used, but the reservation is why tens of thousands of OS threads strain a system. Go instead starts goroutines with stacks of a few kilobytes,²⁸ and Java keeps virtual-thread stacks as small objects on the heap; both grow on demand.²⁹

Creating a thread

In C with POSIX threads, a thread is a function started with pthread_create and waited for with pthread_join. On Linux, pthread_create allocates a stack and calls clone (or its newer form, clone3) with flags that share the address space, file descriptors, file system information and signal handlers, and place the new task in the caller’s thread group.¹³ Creating a thread this way is much cheaper than creating a process, but still involves a system call and kernel data structures, which is what user-level threads avoid.

In Go, the same idea is a keyword. This starts a hundred thousand goroutines, which would be reckless with OS threads (it needs Go 1.22 or later, where each loop iteration gets its own i):

package main

import (
	"fmt"
	"sync"
)

func main() {
	var wg sync.WaitGroup
	results := make([]int, 100_000)
	for i := range results {
		wg.Add(1)
		go func() { // a new goroutine, not a new OS thread
			defer wg.Done()
			results[i] = i * i
		}()
	}
	wg.Wait()
	fmt.Println(results[99_999]) // 9999800001
}

Context switching

When the kernel moves a CPU core from one thread to another, it performs a context switch.

1. Control enters the kernel, through a timer interrupt (the running thread’s time slice is up), a system call that blocks (it is waiting for I/O or a lock), or an interrupt that wakes a more important thread.
2. The kernel saves the running thread’s registers, including its stack pointer and program counter.
3. The scheduler chooses the next thread to run.
4. If the next thread belongs to a different process, the kernel switches the MMU to that process’s page tables. Switching between threads of the same process skips this step, which is one reason it is cheaper.
5. The kernel restores the next thread’s registers and returns to user mode, where it continues exactly where it was last stopped.

The switch itself takes on the order of microseconds. Its indirect cost is often larger: the new thread finds the caches and TLB full of the previous thread’s data, and runs slowly until they warm up again.³⁹ A user-level runtime can switch between its own threads without entering the kernel at all, which is how Go and Java virtual threads keep switches cheap.

Scheduling threads

The scheduler (described in What Is an Operating System?) schedules threads, not processes: a process with eight runnable threads can occupy eight cores at once. Two refinements matter for threaded programs:

• Affinity. The scheduler prefers to keep a thread on the core it last ran on, where its data may still be in cache, and programs can pin threads to particular cores.
• Simultaneous multithreading. A core with SMT (Intel’s Hyper-Threading) appears to the operating system as two (on some processors more) logical CPUs, so two threads can share one physical core and its execution units.

How much a program speeds up with more threads is limited by the part of it that cannot run in parallel. Gene Amdahl’s 1967 argument, now called Amdahl’s law, says that if a fraction s of the work is serial, no number of processors can make the program more than 1/s times faster.⁴⁰ A program that is 10 percent serial will never run more than ten times faster, however many cores it gets.

Synchronisation

Threads share memory, so whenever two of them access the same data and at least one writes, the program must control the order. Otherwise it has a data race, and the result depends on how the scheduler happened to interleave the threads, which changes from run to run.

The building blocks, all ultimately built on atomic instructions in the processor, are:

Condition variables come from monitors, developed by Per Brinch Hansen and Tony Hoare (1974), which bundle data with the procedures allowed to touch it and let a procedure wait inside until a condition holds.⁴¹ The classic use is a bounded buffer between a producer and a consumer:

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

#define SIZE 8
static int buf[SIZE], count = 0, head = 0, tail = 0;
static pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
static pthread_cond_t not_empty = PTHREAD_COND_INITIALIZER;
static pthread_cond_t not_full = PTHREAD_COND_INITIALIZER;

static void put(int v) {
    pthread_mutex_lock(&lock);
    while (count == SIZE)                     /* re-check after every wake-up */
        pthread_cond_wait(&not_full, &lock);  /* sleeps with the lock released */
    buf[tail] = v; tail = (tail + 1) % SIZE; count++;
    pthread_cond_signal(&not_empty);
    pthread_mutex_unlock(&lock);
}

static int get(void) {
    pthread_mutex_lock(&lock);
    while (count == 0)
        pthread_cond_wait(&not_empty, &lock);
    int v = buf[head]; head = (head + 1) % SIZE; count--;
    pthread_cond_signal(&not_full);
    pthread_mutex_unlock(&lock);
    return v;
}

static void *producer(void *arg) {
    (void)arg;
    for (int i = 1; i <= 100; i++)
        put(i);
    put(-1);                                  /* tell the consumer to stop */
    return NULL;
}

int main(void) {
    pthread_t t;
    pthread_create(&t, NULL, producer, NULL);
    long sum = 0;
    for (int v; (v = get()) != -1; )
        sum += v;
    pthread_join(t, NULL);
    printf("%ld\n", sum);                     /* 5050 */
    return 0;
}

The while loops matter: a woken thread must check its condition again, because another thread may have got there first, and POSIX allows spurious wake-ups.⁴²

Locks are made fast by keeping the common case out of the kernel. A Linux futex is an integer in shared memory that threads update with atomic instructions; only when a thread actually has to wait, or wake a waiter, does it make a system call.¹⁶ An uncontended lock therefore needs only an atomic instruction, with no system call at all.

Locks have their own failure modes. A deadlock happens when threads wait for each other in a cycle; the usual cure is to always take locks in the same order. Priority inversion happens when a low-priority thread holding a lock is starved by medium-priority work while a high-priority thread waits for that lock. Contention happens when so many threads want the same lock that they spend their time queuing rather than working.

Memory models

Modern processors and compilers reorder memory operations for speed. A single thread cannot tell, but another thread can. Leslie Lamport defined the intuitive ideal in 1979 as sequential consistency: the result is as if all threads’ operations ran in some single interleaved order, each thread’s in program order.⁴³ Real hardware does not guarantee it, so languages specify a memory model: a contract saying which reorderings are allowed and which operations (locks, atomics, volatile in Java) restore order. Hans Boehm showed in 2005 that threads cannot be added correctly to a language purely as a library, because the compiler has to know the rules too.⁴⁴ Java’s memory model had been rebuilt in 2004, and C and C++ adopted one in 2011, which Boehm’s work helped shape.²³²⁴²⁵ The practical rule they give programmers: a program without data races behaves as if it were sequentially consistent.

Signals and threads

Signals predate threads, and the combination is awkward. A signal sent to a process is delivered to any one of its threads that has not blocked it, so multithreaded programs usually block signals in every thread but one, which waits for them explicitly.⁴⁵ Calling fork in a multithreaded program copies only the calling thread; any lock another thread held at that moment stays locked forever in the child, which is why a child of a threaded program should call exec almost immediately.³¹

Putting it together: serving many clients

How a network server handles many clients at once is a direct choice between the models in this article.

Real systems mix them. nginx runs one event loop per worker process, and is usually configured with one worker per CPU core.⁴⁶ Web browsers went the other way for safety. Chrome ran web pages in separate renderer processes from its first release in 2008, by default giving each site instance (roughly, a group of related tabs on one site) its own process, so one crashing page did not take the others down.⁴⁷⁴⁸ Strict per-site isolation, including cross-site frames inside a page, became the default only with Site Isolation in Chrome 67 in 2018.⁴⁹

Why it matters

Processes and threads are the two answers to the question “what is running?”, and they sit at opposite ends of a trade-off. Processes give isolation and pay for it in memory and communication. Threads give sharing and pay for it in coordination. Most of the bugs that are hardest to reproduce, such as races, deadlocks and memory corruption that appears only under load, come from treating threads as if they were processes. Many of the performance problems, such as servers with thousands of idle stacks and programs that do not speed up on more cores, come from treating processes or threads as free. Knowing what each one really costs, and what it really shares, is the start of reasoning about any concurrent program.

References