3 Threads and Multithreading

Processes and threads

A process is a running program together with operating-system resources, such as a virtual address space and access to files. A thread is a sequence of execution within a process. A process may contain one thread or several.

Each thread has its own execution state, including a program counter, CPU registers, and stack. Threads in the same process share the process’s code, global data, heap, and many process resources. In POSIX systems, for example, threads share global memory and open file descriptors but have distinct stacks and thread IDs. The exact resources shared depend on the operating system and its interfaces.

Separate processes typically have separate address spaces, while threads in one process share an address space. Each process has its own execution state; each thread has its own registers, program counter, and stack. Separate processes often require interprocess communication (IPC) to communicate, whereas threads can communicate through shared variables.

Processes provide stronger separation: a process’s memory is generally protected from other processes. Threads can access shared process memory, so a faulty write by one thread may affect its fellow threads. For example, a web browser might isolate work in separate processes, while one application process might use several threads for independent tasks.

What multithreading enables

Multithreading means using multiple threads within one process. It can improve responsiveness when one thread waits for input or file access while another continues working. For example, a word processor can keep accepting keystrokes while another thread saves a document.

Concurrency means tasks make progress during overlapping periods. On a single core, the operating system can interleave their execution. Parallelism means tasks execute simultaneously, for example on separate processor cores. Multithreading can support both, but creating threads does not guarantee that a program will run faster.

Sharing memory is convenient, but creates risks when threads access the same data. If two threads update the same value without coordination, their operations can overlap and produce an incorrect result; this is a race condition. Locks and other synchronization tools coordinate access to shared data. Poor coordination can cause bugs such as deadlocks.

Threading models

Threading models describe how user threads—threads managed by a program or runtime—map to kernel threads, which the operating system can schedule. The mapping affects parallel execution and what happens when a thread blocks.

Many-to-one

In the Many-to-one model, many user threads map to one kernel thread. Managing threads in user space can be efficient, but a blocking system call may stop the sole kernel thread and prevent the other user threads from running. Because only one kernel thread is available, the process cannot run its threads in parallel on multiple cores.

One-to-one

In the One-to-one model, each user thread maps to a kernel thread. The operating system can schedule different threads independently, including on multiple cores, and one thread blocking does not necessarily prevent others from running. The trade-off is that creating and managing many kernel threads uses more system resources.

Many-to-many

In the Many-to-many model, many user threads are multiplexed over a set of kernel threads. This allows a program to have more user threads than kernel threads while still letting the operating system schedule multiple kernel threads. The model combines user-level flexibility with the potential for parallel execution, but requires a more complex implementation.

The two-level model is a variation of many-to-many that also allows some user threads to be bound to particular kernel threads. These models describe general design choices; specific operating systems and runtimes differ in their implementations.