Process vs Thread: The Difference

A process and a thread are the two fundamental units of execution an operating system manages, and confusing them is a common source of concurrency bugs. The short version: a process is an isolated program with its own memory, while a thread is a unit of execution that runs inside a process and shares that process's memory with its sibling threads.

What a process is

A process is an instance of a running program. When you launch an application, the operating system creates a process for it and gives that process its own private virtual address space, its own file descriptors, and its own set of resources. Two processes cannot read or write each other's memory directly, because the OS maps each process to a separate region of physical memory and enforces that boundary in hardware via the memory management unit.

Every process contains at least one thread, often called the main thread. The process owns the resources; the thread does the actual executing. Because each process is isolated, a crash in one process normally cannot corrupt another process's memory. This is why modern browsers run tabs or sites in separate processes: a fault in one page does not bring down the whole browser.

What a thread is

A thread is the smallest sequence of instructions the OS scheduler can run independently. All threads inside the same process share the process's heap, global variables, and open file descriptors, but each thread keeps its own stack, its own program counter, and its own register set. That shared memory is what makes threads fast to communicate but also dangerous: two threads can touch the same variable at the same time.

Creating a thread is cheaper than creating a process because the thread reuses the parent process's address space instead of asking the OS to set up a brand-new one. Switching between threads of the same process is also typically faster than switching between processes, since the memory mappings do not need to change.

How they differ side by side

The practical distinctions come down to isolation, memory, communication cost, and failure blast radius.

How they actually run on the CPU

On a multi-core machine, the OS scheduler can place different threads or processes on different cores so they run truly in parallel. On a single core, the scheduler time-slices, rapidly switching between runnable threads to create the illusion of simultaneity, which is concurrency rather than parallelism.

It is worth separating two ideas. Concurrency means structuring a program to handle multiple tasks that overlap in time. Parallelism means literally executing more than one task at the same instant on separate hardware. Threads and processes both enable concurrency, but only multiple cores deliver real parallelism.

When to use a process vs a thread

Reach for threads when tasks need to share a lot of in-memory state cheaply and the failure of one task does not need to be isolated. Common cases include a server handling many simultaneous connections, a UI keeping a responsive main thread while background threads do work, or splitting a CPU-heavy computation across cores when the language allows true parallel threads.

Reach for processes when you need fault isolation, security boundaries, or independent scaling. Examples include running untrusted plugins, sandboxing browser tabs, or scaling a web application by forking multiple worker processes that each handle requests. Processes are also the right tool when a runtime's threading model limits parallelism (see the pitfalls below).

Many real systems combine both: a pool of worker processes, each running an internal pool of threads. This buys isolation between workers and cheap concurrency within each one.

The pitfalls that bite developers

Threads sharing memory introduces race conditions, where the result depends on the unpredictable order in which threads execute. The classic fix is a mutex or lock that serializes access to shared data, but locks bring their own hazard: deadlock, where two threads each wait on a lock the other holds and neither proceeds. Holding locks for too long also serializes work that you wanted to parallelize, erasing the benefit.

Some language runtimes constrain threading. CPython's Global Interpreter Lock historically allowed only one thread to execute Python bytecode at a time, so CPU-bound Python work often scales better with multiple processes than with threads; threads still help for I/O-bound work. JavaScript runtimes such as browsers and Node.js use a single-threaded event loop for application code and offload parallel work to Web Workers or worker threads, which communicate by message passing rather than shared variables. Always check your platform's model before assuming threads give you parallelism.

Inter-process communication is the cost you pay for isolation. Because processes cannot share variables, they exchange data through pipes, sockets, message queues, or explicitly shared memory segments, which means serializing and copying data. That is slower than a thread reading a shared object, so chatty IPC can dominate runtime. If you are exchanging data over the network between processes or machines, the transport choice matters too; our explainer on TCP vs UDP covers the tradeoffs, and WebSockets vs server-sent events compares persistent connection styles.

Finally, watch resource lifecycle. Threads that are never joined become detached and can leak; processes that exit without their children being reaped become zombies on Unix-like systems. Background and scheduled work has the same concern: if you orchestrate recurring jobs, our cron parser helps you reason about timing, and when sizing concurrent API load it pairs well with sound rate-limiting strategies.

A simple mental model

Think of a process as a house with locked doors and its own utilities, and threads as the people living inside that house. The people share the kitchen and the fridge freely, which is convenient but means they can collide over the same resource. To talk to someone in another house, you have to send a message through the door rather than just reaching into their fridge. That isolation is the whole point: processes trade speed of communication for safety, while threads trade safety for speed of communication.

Frequently Asked Questions