Thread vs Process

In concurrent programming, two fundamental abstractions dominate: processes and threads. Both enable concurrent execution. Both allow programs to perform multiple tasks simultaneously. Yet they represent profoundly different approaches to structuring concurrent systems—with far-reaching implications for performance, safety, communication, and design complexity.

Understanding the distinction between threads and processes is not merely academic. It directly impacts how you architect systems, debug failures, and reason about program behavior. Choosing incorrectly leads to either:

• Unnecessary overhead: Using processes when threads would suffice, paying the cost of isolation you don't need
• Safety vulnerabilities: Using threads when processes are warranted, risking catastrophic failures from shared state bugs

This page provides the comprehensive comparison you need to make informed decisions.

At the core, the difference between threads and processes lies in what they share vs. what they own exclusively. This single distinction cascades into every aspect of their behavior.

The Process: An Isolated Container

A process is a complete, self-contained execution environment. It owns:

• Its own virtual address space (code, data, heap, stack)
• Its own file descriptor table
• Its own signal handlers and pending signals
• Its own resource limits and accounting
• Its own security credentials (user ID, group ID, capabilities)

The Thread: A Shared Execution Flow

A thread is a single path of execution within a process. It has:

• Its own program counter, registers, and stack
• Its own thread ID and scheduling state
• Its own thread-specific data (TLS)

But it shares with sibling threads:

• The entire virtual address space
• All file descriptors
• Signal handlers
• Current working directory
• User and group IDs
• Resource limits

The memory model is where the thread vs. process distinction has the most profound implications. Understanding how each model structures memory reveals why they behave so differently.

Process Memory Model: Complete Isolation

Each process has its own virtual address space, typically spanning the full addressable range (e.g., 256 TB on 64-bit Linux). This address space is completely isolated from other processes:

• A pointer in Process A cannot reference memory in Process B
• Writing to address 0x10000 in Process A has no effect on address 0x10000 in Process B
• Each process thinks it has the entire address space to itself

This isolation is enforced by hardware memory protection (page tables, MMU). Attempts to access another process's memory cause a segmentation fault—the kernel terminates the offending process.

Thread Memory Model: Shared Address Space

All threads within a process share the same virtual address space:

• A pointer from Thread A is valid in Thread B
• Writing to address 0x10000 from Thread A modifies the same memory Thread B sees
• Changes are immediately visible (modulo caching and memory ordering)

Memory Isolation Trade-offs:

One of the primary motivations for using threads over processes is performance. But the performance story is nuanced—threads aren't uniformly faster. Let's examine the specific areas where they differ.

Perhaps the most critical distinction between threads and processes is fault isolation—what happens when something goes wrong.

Thread Failure Modes:

When a thread encounters a fatal error (segmentation fault, unhandled exception, calling abort()), the entire process terminates. There is no recovery:

Thread 1: Working fine...
Thread 2: Dereferences nullptr → SIGSEGV
Result: All threads terminated. Application dead.

Beyond crashes, threads can corrupt shared state silently:

Thread 1: health_check_passed = true;
Thread 2: (buggy code overwrites health_check_passed)
Thread 1: if (health_check_passed) { ... } // Wrong branch taken!

This corruption is insidious—the program continues executing but is now in an inconsistent state. Debugging such issues is notoriously difficult.

Process Failure Modes:

When a process crashes, other processes are unaffected:

Process A: Working fine...
Process B: Segmentation fault
Result: Process B terminated. Process A continues normally.

Processes cannot corrupt each other's memory. Hardware-enforced isolation guarantees that a pointer in Process B cannot reference (or overwrite) memory in Process A.

Real-World Architecture Decision: Chrome Browser

Google Chrome was famously designed with a multi-process architecture specifically for fault isolation:

• Each tab runs in a separate renderer process
• One tab crash doesn't bring down other tabs
• Malicious website code is sandboxed to its process
• Plugin crashes (Flash) don't crash the browser

The performance cost of process isolation is deemed worthwhile for the reliability and security gains. This is a deliberate architectural trade-off.

How concurrent execution units communicate fundamentally shapes application architecture. Threads and processes employ radically different communication mechanisms.

The choice between threads and processes has significant implications for system resource usage, particularly as concurrency scales.

Memory Overhead:

• Per-Process: Each process requires its own page tables, kernel structures, signal tables, file descriptor tables, etc. A minimal process on Linux consumes 1–4 MB of virtual memory (mostly shared library mappings, but overhead is real).

• Per-Thread: Each thread requires a stack (default 8 MB virtual, but typically only 4–12 KB actually allocated initially due to lazy page allocation) plus a small kernel structure (~2 KB).

Scalability Limits:

Practical Scalability Considerations:

Thousands of Threads:

• Feasible for I/O-bound workloads where most threads are blocked
• Each blocked thread consumes stack space but no CPU
• Scheduler overhead increases with thread count
• Context switch locality degrades with many threads

Thousands of Processes:

• Common in high-availability systems (e.g., Erlang processes)
• More memory overhead but complete isolation
• Process pools with limited workers are typical pattern
• Kernel structures become the limiting factor

The Real Scalability Solution: Asynchronous I/O

For true scalability (millions of concurrent connections), neither massive thread nor process counts work. Systems like nginx and Node.js use:

• Small thread pool (matching CPU cores)
• Asynchronous, event-driven I/O
• Non-blocking system calls
• Each thread handles thousands of connections via multiplexing

Given everything we've explored, how do you decide between threads and processes? Here's a systematic framework based on your requirements.