Process vs. Thread: Understanding Their Structural Differences
Koyejo Adinlewa
Full Stack Developer at CELL | Node.js, MongoDB, SQL, Angular | #alx_se #forward_alumni
A high-level guide to how processes and threads are structured, managed, and executed by the Operating System (OS).
Understanding the difference between a process and a thread is one of those foundational operating system concepts that many software engineers encounter early. In this article, I attempt a high-level, structural view of the two—focusing on how processes and threads are structured, how they relate to memory and execution, and what truly separates them in practice.
𝗧𝗵𝗲 𝗢𝗿𝗶𝗴𝗶𝗻
Before diving into processes and threads, let's start with the basics: What is a program? For everyday users of computers and phones, a program is simply an "app." Technically, it's an executable file (like a .exe) containing a set of instructions that tell the CPU how to run it. When you launch an app, the code within that executable file directs the CPU on what actions to perform. So, remember: before a process or a thread can exist, there must first be a program.
𝗧𝗵𝗲 𝗣𝗿𝗼𝗰𝗲𝘀𝘀 𝗢𝗳...
Simply and informally put, a process is a program in execution. A program (app) is made up of a series of instructions that allow it to behave the way it does. These instructions are executed in order by the CPU—as defined by the program logic—and it is this ongoing execution that is referred to as a process: the CPU is in the process of executing the instructions for that program.
When you launch a program, several things happen behind the scenes to transform it into a process. First, its executable file is loaded into memory—specifically into a block of memory referred to as an address space, assigned by the operating system (OS). This space is where all of the program’s independent operations will take place. Within this address space, the program’s code and data are organized into regions such as:
1. Text region – holds the instructions as compiled code (your code).
2. Data region – contains fixed data like global variables and constants.
3. Heap – stores dynamic data created during runtime (like user input).
4. Stack – keeps track of function calls and temporary execution data.
This address space forms part of what’s called the process state—a complete record of everything the OS needs to manage and track the process. This includes not just memory limits, but also which files the process has opened, which hardware devices it's talking to, scheduling priority, references to spawned threads, and more. The operating system keeps all of this information in a data structure called the Process Control Block (PCB).
One of the most important pieces of information within the PCB is a reference to the process’ CPU state. While the process state helps the OS manage the process as a whole, the CPU state helps keep track of the current execution status of the process—i.e., it tells the CPU exactly what was happening when the process last ran or what needs to happen next when it’s resumed. The CPU state includes:
1. Program counter – points to the memory address of the next instruction to execute.
2. Instruction register – holds the current instruction being executed.
3. Stack pointer – tracks the current position in the call stack
4. General-purpose registers – temporary storage for intermediate calculations and values.
Recommended by LinkedIn
5. Flags/status bits – indicate conditions such as zero results, overflow, or comparison outcomes.
The CPU state is what enables the CPU to pause, resume, or switch between multiple processes or tasks efficiently—without losing track of where it left off or mixing up the execution details of different programs.
By maintaining a clear distinction between process state and CPU state, we now have the foundation to understand the key structural difference between processes and threads: while each thread in a process has its own CPU state, it shares the process state with its parent process and sibling threads.
𝗧𝗵𝗿𝗲𝗮𝗱 – 𝗔 𝗨𝗻𝗶𝘁 𝗪𝗶𝘁𝗵𝗶𝗻 𝘁𝗵𝗲 𝗣𝗿𝗼𝗰𝗲𝘀𝘀
An easy way to think of a thread is as a lightweight version of a process. It is the smallest unit of CPU utilization. Unlike a process, a thread does not have its own separate address space. Instead, it runs within the memory limits of the process that created it. This is a key structural difference: while processes are independent entities with their own dedicated memory, threads are components within a process, sharing its memory resources—such as the text, data, and heap regions. However, each thread maintains its own stack, which is essential for managing function calls and local variables specific to that thread.
The main utility of threads is to facilitate concurrency of tasks within a single process. Concurrency means performing many tasks “simultaneously.” While the overall process state (like the address space, open files, etc.) is shared among all threads within a process, each thread requires its own CPU state (including its own program counter, registers, and stack pointer). This is because the CPU enables concurrency by switching between the execution contexts (CPU states) of different processes and tasks. These independent contexts allow the OS to pause and resume threads without interfering with one another.
When a program becomes a process, it starts with a main thread, which is assigned the initial CPU state for that process. That thread can then spawn others, each with its own CPU state but access to the shared process state. The operating system tracks the process as a whole using the Process Control Block (PCB) and coordinates execution across threads using their individual CPU states. This architecture allows different tasks in a program—like downloading content and updating the interface—to run concurrently in a lightweight and efficient way.
A Working Example: YouTube
Let's consider the YouTube app on your phone or computer.
Conclusion
Understanding the structural difference between a process and a thread goes beyond just terminology — it’s a foundational concept that shapes how we design and reason about concurrent systems. By breaking down how they manage memory, execution, and resources, we gain a clearer mental model for building more efficient, predictable, and maintainable software. Whether you’re designing a multi-threaded application or optimizing system performance, appreciating the distinct roles of processes and threads is key to making informed engineering decisions.
Software Engineer
6dThanks for sharing, Koyejo. I have a mental model of a thread like a department staff. A process is the department. A process will always have at least one staff member.