Threads versus Processes
Threads share one address space within a process; processes have separate memory. The distinction shapes communication, isolation, and cost.
Two units of execution
A process is an independent program instance with its own private memory and resources. A thread is an execution stream inside a process; all threads of a process share its address space. This single difference, shared versus private memory, drives everything else about how they communicate and scale.
Communication
Threads communicate implicitly by reading and writing shared variables, which is fast but requires synchronization to avoid races. Processes have no shared memory by default, so they communicate through explicit mechanisms: pipes, shared-memory segments, or, across nodes, message passing.
Cost and isolation
- Threads are cheap to create and switch; processes are heavier
- Threads share resources; a crash or corruption in one can affect all
- Processes are isolated; a fault in one does not corrupt another's memory
The HPC mapping
On a cluster the two combine. Across nodes, which have no shared memory, work is split into processes coordinated by MPI. Within a node, each process spawns threads (via OpenMP) to use all cores of the shared memory. This MPI+X hybrid matches the hardware: message passing between nodes, threading inside them.
A Note on Runtimes
Some language runtimes complicate the picture. Python's global interpreter lock, for example, prevents pure-Python threads from running CPU-bound work in parallel, so Python HPC leans on processes (via mpi4py) or on releasing the lock inside native libraries. Knowing the runtime's threading model is essential before choosing an approach.