Threads and Shared Memory

A process normally has its own virtual address space. Threads within that process share it, including program code, global variables and heap data. They also share process resources such as open files, which are not themselves memory addresses. Threads do not gain separate memory protection from each other.

Each thread has its own execution state: program counter, registers and stack pointer. It normally uses its own stack for local calls and variables. These stacks still lie in the shared address space; a pointer can let another thread reach a stack variable. In an example where A uses local a, B uses local b, and both update global total, total is the explicitly shared variable.

Creating a thread usually needs less address-space setup because it reuses its process's mappings. It still needs execution state and normally a stack. Creating a process establishes a separate address space, though techniques such as copy-on-write can avoid copying all memory immediately. Actual costs depend on the OS and workload.

With OS-scheduled threads, one thread can wait for disk input while another runnable thread computes, even on one CPU. Multiple CPUs may also run threads in parallel. During that wait, progress requires another thread that is runnable and able to proceed. The next trace shows why shared updates also need coordination.

Switching between threads of one process keeps the same process memory mappings. Each thread's execution state still has to be saved and restored. Switching to a different process may also require changing the active address-space context. Cache effects and OS details still affect the cost; a thread switch is not free.

Conflicting accesses to shared data need coordination. It is not enough to coordinate only writers if readers need a consistent result. For a shared pair that must match, coordinate reading the pair with changing it, so a reader cannot observe only half an update. Sharing memory by itself provides no such rule.