Process, Threads, Tasks

Most engineers use the words process, thread, and task interchangeably. They are not the same thing. Using them wrong does not just make you sound imprecise - it means you are missing a mental model that explains why applications behave the way they do, why some crash without warning, why some slow down under load, and why some handle thousands of connections while others fall over at ten.

These three concepts sit at the foundation of how every program you have ever run actually works.

Ask a fresher what a process is and they say "a running program." Ask what a thread is and they say "a lightweight process." Ask what a task is and they go quiet or say "something in a to-do list."

None of these answers are wrong exactly. But none of them are useful either. They are surface definitions that break down the moment you need to debug something real - a service that is consuming too much memory, an application that is freezing under load, a program that crashes when two things happen at the same time.

The concept that unlocks all three is simple: your CPU can only execute one instruction at a time on one core. Everything else - the appearance of doing multiple things simultaneously - is an illusion created by switching between work very fast. A process, a thread, and a task are three different answers to the same question: how do we organise work so the CPU can switch between it efficiently?

A process is a running program with its own isolated chunk of memory, its own file descriptors, and its own identity in the eyes of the operating system.

When you start nginx, the OS creates a process. It allocates memory that belongs exclusively to that process. It assigns a PID - process ID - so the kernel can track it. It gives it open file handles, network connections, and everything else that program needs to run. That collection of resources, tied together under one PID, is a process.

The key word is isolated. A process cannot read another process's memory. If your nginx process crashes, your database process keeps running. They do not share memory. They cannot accidentally overwrite each other's data. The OS enforces this boundary at the hardware level.

This isolation is the main reason processes exist. It is also their main cost.

Creating a process is expensive. The OS has to allocate a fresh memory space, copy the parent's environment, set up file descriptor tables, initialise kernel data structures for the new PID. This takes time and memory. Switching between processes - called a context switch - requires saving the entire state of the current process and loading the entire state of the next one. CPU caches get invalidated. It is not catastrophic but it adds up.

The other cost is communication. Because processes are isolated, getting data from one process to another requires going through the OS - pipes, sockets, shared memory segments, message queues. None of these are free. Two functions in the same process can share data by reading the same variable. Two separate processes have to explicitly pass data through a channel.

Use a process when isolation matters more than speed. A web server that handles untrusted user input in a separate process protects itself - if that process gets compromised, the main process is unaffected. Chrome runs each browser tab as a separate process for exactly this reason. One malicious tab crashes its own process, not your entire browser.

A thread is a unit of execution that lives inside a process and shares that process's memory.

One process can have many threads. All of them share the same memory space, the same file descriptors, the same network connections. What each thread owns independently is just its own stack - the record of which functions it is currently executing and what local variables those functions are using.

Threads exist because processes were too expensive for certain problems.

Imagine a web server that needs to handle 1000 simultaneous connections. Creating 1000 separate processes is possible but wasteful - each process gets its own isolated memory space, its own OS overhead, its own context switch cost. Most of that memory is identical across all 1000 processes. You are paying for isolation you do not need.

Threads solve this. One process, 1000 threads. All 1000 share the same memory. Creating a new thread costs a fraction of what creating a new process costs. Switching between threads inside the same process is faster than switching between processes because the memory space does not change - CPU caches stay warm.

The cost of threads is the cost of sharing.

When two threads share memory, they can read and write the same data simultaneously. If thread A is halfway through updating a value and thread B reads that value at exactly that moment, thread B gets garbage - a half-updated value that is neither the old state nor the new state. This is a race condition.

Race conditions are one of the hardest bugs to reproduce and debug. They do not happen every time. They happen when two threads happen to execute in a specific order, which depends on timing, load, and CPU scheduling decisions you have no control over. A bug that appears once every thousand requests and disappears when you add a log line is almost always a race condition.

The fix is synchronisation - locks, mutexes, semaphores. These mechanisms force threads to take turns accessing shared data. They work, but they add complexity and can introduce new problems. Two threads each waiting for the other to release a lock - a deadlock - will freeze your application permanently with no error message.

Use a thread when you need concurrency within a single program, your tasks share data, and the overhead of separate processes is not justified. Use it carefully.

A task is a unit of work that is scheduled by your application, not by the operating system.

That distinction matters. The OS schedules processes and threads. It decides when each one runs, for how long, and on which CPU core. Your application has no say in that. A task is different - the application itself controls when a task runs, when it pauses, and when it resumes.

To understand why tasks exist, you need to understand the problem threads could not fully solve.

Threads are good at parallel work - two threads doing two completely independent things simultaneously on two CPU cores. But a lot of real application work is not parallel in that way. It is waiting. A web server handling 1000 connections is not doing 1000 things simultaneously. It is mostly waiting - waiting for a database query to return, waiting for a file to load from disk, waiting for a network response to arrive.

If you use one thread per connection, 1000 connections means 1000 threads. Most of those threads are sitting idle, waiting. You are paying the memory and context switch cost of 1000 threads to do very little actual work. At 10,000 connections this becomes a serious problem. At 100,000 it is impossible.

Tasks solve this with a different model. Instead of blocking a thread while waiting, a task pauses itself - it says "I am waiting for this network response, I will give up the thread for now and resume when the response arrives." Another task immediately picks up that thread and starts its own work. When the first task's response arrives, it gets scheduled to resume on a free thread.

This is called cooperative multitasking. Tasks voluntarily yield control rather than being forcibly switched out by the OS. The mechanism that makes this work is the event loop.

The event loop is a single loop running inside your application that continuously checks: is any task ready to resume? If yes, run it until it pauses again. If no, wait. The event loop is what Node.js runs on. It is what Python's asyncio runs on. It is what makes a single-threaded application handle thousands of simultaneous connections without breaking a sweat.

The words async and await that you see in modern code are just syntax for this. Async marks a function as a task - something that can pause and resume. Await is the pause point - the moment a task voluntarily yields and says "wake me up when this is ready."

The cost of a task is almost nothing compared to a thread. No OS involvement. No kernel data structures. No context switch overhead. Just a small record of where execution was paused and what to do when it resumes. You can have hundreds of thousands of tasks running inside a single thread where you could never have hundreds of thousands of threads.

The limitation is that tasks are cooperative. A task that never yields - one that does heavy computation without any waiting - blocks the entire event loop. Every other task waiting to run is frozen until that one finishes. This is why tasks work beautifully for IO-bound work - network calls, database queries, file reads - and poorly for CPU-bound work like image processing or encryption.

The three concepts sit at different levels and solve different problems. Here is how they actually compare.

Memory is the sharpest distinction. A process owns its memory entirely - nothing outside can touch it without going through the OS. Threads inside the same process share all memory - every thread sees the same heap, the same global variables, the same open files. Tasks share memory too because they run inside threads, but since tasks cooperate rather than run simultaneously, the shared memory problem is far less dangerous. Two tasks do not run at exactly the same instant, so the race conditions that plague threads are mostly absent in task-based code.

Scheduling is who decides when each one runs. The OS kernel schedules processes and threads. Your application has no control over when a thread gets CPU time or for how long. Tasks are scheduled by the application's event loop. The application decides which task runs next based on which ones are ready to resume. This is why tasks are called cooperative - they work with the scheduler rather than being managed by it.

Isolation determines blast radius when something goes wrong. A process crash affects only that process. The OS cleans up its memory, closes its file descriptors, and everything else keeps running. A thread crash is more dangerous - because threads share memory, a thread that corrupts memory or hits an unhandled exception can take down the entire process and every other thread inside it. A task failure is usually contained - a task that throws an error fails on its own, and the event loop moves to the next task - but this depends on how the application handles task errors.

Cost is where the practical tradeoffs live. Creating a process is the most expensive - new memory space, OS data structures, full context switch overhead. Creating a thread is cheaper - shared memory space, lighter OS structures, faster context switch. Creating a task is nearly free - no OS involvement, just an application-level record of paused execution state.

Here is the comparison in plain terms:

A process is a house. It has its own land, its own walls, its own utilities. Nothing outside can walk in uninvited. Expensive to build, but completely self-contained.

A thread is a room inside that house. It shares the walls, the electricity, the plumbing. Cheap to add. But everyone in the house can walk into every room. Leave something on the table and your housemate might move it.

A task is a person in that room deciding what to do next. They are not a separate room - they are just a unit of work happening inside one. They can pause what they are doing, let someone else use the desk, and come back later. No construction required.

The choice between process, thread, and task is not always yours to make. Frameworks and runtimes make it for you. Node.js uses tasks and an event loop. Python's multiprocessing library uses processes. Java applications typically use threads. But understanding which model fits which problem helps you choose the right tool and debug the right way when things go wrong.

Use a process when isolation is the priority. If you are running untrusted code, handling sensitive data in a sandboxed environment, or building something where one component crashing must not affect everything else - use separate processes. The cost is higher but the safety boundary is hard. A crashed process does not corrupt your main application's memory.

Use a thread when you have genuinely parallel CPU work and shared data. If you are processing a large dataset and want to split it across cores, threads let multiple CPUs work simultaneously on the same data without the overhead of copying that data between processes. Threads also make sense when your work is parallel and stateful - multiple operations that need to read and modify shared data and where the synchronisation complexity is manageable.

Use a task when your work is IO-bound. If your application spends most of its time waiting - waiting for API responses, database queries, file reads, network connections - tasks are the right model. One thread running an event loop with thousands of tasks handles IO-heavy workloads more efficiently than thousands of threads sitting idle waiting for responses. The memory footprint is lower, the context switch overhead is nearly zero, and the code is easier to reason about than multithreaded code with locks.

The real world rarely uses just one. A production web server might use multiple processes for isolation, a thread pool inside each process for CPU-bound work, and an event loop with tasks inside each thread for handling network IO. Each layer solves a different part of the problem.

When you see an application hanging under load, the mental model helps immediately. Is it CPU-bound? Threads or processes are the fix - add parallelism. Is it IO-bound with too many blocking calls? Tasks are the fix - switch to async IO. Is one component taking down everything else? Processes are the fix - add isolation.

The concepts are simple. The application is always which problem you are actually solving.

Thanks for supporting this newsletter. Y’all are the best!
Until next time!

👋 Find me on Twitter | Linkedin | Connect 1:1

Thank you for supporting this newsletter.

Y’all are the best.