The short answer
Quick answer: A process is a running program with its own private memory. A thread is a path of execution inside a process. Every process has at least one thread, and all threads in a process share the same memory. Processes are isolated from each other, so one crashing does not take down the others, but they are heavier to create and slower to communicate between. Threads are lightweight and share data easily, but a bug in one thread can corrupt or crash the whole process.
| Process | Thread | |
|---|---|---|
| Memory | Own private address space | Shares the process's address space |
| Has its own | Code, heap, open files, at least one thread | Stack, CPU registers, program counter |
| Creation cost | Higher | Lower |
| Switching cost | Higher (address space changes) | Lower |
| Communication | Pipes, sockets, shared memory, files | Direct access to shared variables |
| If it crashes | Other processes keep running | The whole process usually dies |
| Main risk | Overhead | Race conditions and deadlocks |
What a process is
When the operating system runs a program, it creates a process: a container holding everything the program needs. That includes a private virtual address space, a table of open files and network connections, security credentials, and one or more threads.
The key property is isolation. Process A cannot read or write process B's memory. If your music player crashes, your editor keeps working, because the operating system and CPU enforce the boundary.
What a thread is
A thread is the thing the CPU actually runs. Each thread has:
- Its own stack, holding its function calls and local variables.
- Its own program counter and CPU registers, recording where it is.
Everything else is shared with the other threads in the same process: global variables, heap memory, open files. Two threads can read the same object without copying it, simply because they both have its address.
A useful picture: a process is a house, and threads are the people living in it. Everyone has their own to-do list (the stack), but they share the kitchen and everything in it.
Why switching costs differ
A CPU core runs one thread at a time. To give the illusion of many things happening at once, the scheduler performs a context switch: save the current thread's registers, load another's, and continue.
Switching between two threads of the same process is relatively cheap, because the memory mapping stays the same. Switching to a thread in a different process also changes the address space, which invalidates cached address translations and makes the CPU cache less useful for a while. That indirect cost is often larger than the switch itself.
Concurrency vs parallelism
These two words are often mixed up:
- Concurrency means dealing with several tasks in overlapping time periods. One core can do it by switching quickly.
- Parallelism means literally running several tasks at the same instant, which needs several cores.
Threads give you both: on a multi-core machine, different threads can run in parallel on different cores.
The danger of shared memory
Sharing memory is the thread's superpower and its curse. Consider two threads both running counter = counter + 1. That single line is really three steps: read the value, add one, write it back. If both threads read 5 before either writes, both write 6, and one increment is lost.
This is a race condition: the result depends on timing. Such bugs are notoriously hard to reproduce, because they may appear once in a million runs.
The standard fixes:
- Mutex (lock). Only one thread at a time may enter a protected section.
- Atomic operations. CPU instructions that do the read-modify-write as one indivisible step.
- Message passing. Threads do not share data at all; they send each other messages through queues.
- Immutable data. Data that never changes is always safe to share. See why immutability matters.
Locks introduce their own problem. In a deadlock, thread 1 holds lock A and waits for lock B, while thread 2 holds B and waits for A. Neither can ever continue.
How processes talk to each other
Because processes do not share memory by default, they use inter-process communication (IPC):
- Pipes, such as
ls | grep txtin a shell. - Sockets, which also work across machines.
- Shared memory, where both processes map the same region explicitly.
- Files and signals.
IPC is slower than touching a shared variable, because data usually has to be copied and the kernel is involved.
When to use which
| Situation | Good choice | Why |
|---|---|---|
| Running untrusted or crash-prone code | Processes | Isolation contains the damage |
| CPU-heavy work on shared data | Threads | No copying between workers |
| Many slow network or disk operations | Async I/O or threads | Most time is spent waiting |
| CPU-heavy work in Python | Processes | The global interpreter lock has traditionally limited threads to one core |
| Scaling across machines | Processes | Threads cannot span machines |
Real examples make the trade-off concrete:
- Web browsers such as Chrome run each site in a separate process. As the Chrome team explains in Inside look at modern web browser, this costs memory but means one broken tab cannot crash or spy on another.
- Database servers differ: PostgreSQL uses a process per connection, while MySQL uses threads.
- Node.js runs your JavaScript on a single thread with an event loop, avoiding most locking problems.
There are also lighter alternatives. Green threads, goroutines and coroutines are scheduled by a language runtime rather than the operating system, so a program can run hundreds of thousands of them. Async/await builds on the same idea.
Frequently asked questions
Is a thread faster than a process?
Threads are faster to create and to switch between, and sharing data needs no copying. But "faster" depends on the job: for work that does not share data, processes can perform just as well and are safer.
How many threads should a program use?
For CPU-bound work, roughly one thread per CPU core. For work that mostly waits on I/O, more threads can help, though asynchronous I/O usually scales better than thousands of threads.
Can threads run on different CPU cores?
Yes. The operating system schedules threads, not processes, so threads of the same process can run in parallel on separate cores.
What happens to threads when a process exits?
They all stop. Threads cannot outlive the process that contains them.
Conclusion
Processes give you safety through isolation; threads give you speed through sharing. Most real systems combine them: several processes for fault isolation, a pool of threads inside each for parallel work, and increasingly async code on top for handling many slow operations. The right choice comes down to one question: how much do your tasks need to share?
Related articles
- What Actually Happens When You Run a Program
- How Your OS Decides Which Program Gets the CPU Next
- How Async/Await Works Under the Hood
- What Is the Event Loop and Why Is Node.js Single-Threaded?
Sources and further reading
