Understanding the Differences Between Processes and Threads, Concurrency, and Shared Resources

Many interviewees have been challenged with the question: What is the difference between a process and a thread? This question is more complex than it appears, and we will explore it in depth.

1 Relationship and Differences between Processes and Threads

What is a process

A process is a program with an independent function that executes dynamically on a set of data. It is an instance of a running program, including the program counter, registers, and current values of program variables.

Features of a process

A process depends on a program for its existence; the program is static while the process is dynamic.

The operating system treats a process as an independent unit for resource allocation and scheduling (CPU excluded; threads are the basic unit for processor task scheduling and execution).

Each process has its own address space (code, data, and stack). Address spaces of different processes are isolated.

What is a thread?

Because creating, destroying, and switching processes incurs significant overhead, a lighter‑weight technique was needed. In the 1980s, the concept of a thread emerged: a thread is an execution path within a process, sharing the process’s resources, and its scheduling cost is far lower than that of a process.

Summary of the differences between processes and threads:

Fundamental difference: A process is the basic unit of OS resource allocation, while a thread is the basic unit of processor task scheduling and execution.

Containment relationship: Every process has at least one thread; a thread is part of a process, often called a lightweight process.

Resource overhead: Each process has an independent address space, making process switches costly. Threads share the process’s address space, have separate stacks and program counters, and incur much lower switching overhead.

Impact relationship: If a process crashes, other processes remain unaffected (in protected mode). If a thread crashes, the entire process may be terminated, so multi‑process designs are generally more robust than multi‑threaded ones.

To make the abstract theory more concrete, we use a familiar factory analogy.

In the computer factory, a process is like a workshop that provides design documents, space, and production lines (threads). Threads are the individual production lines. Each line has an operator (CPU) that must read the line’s context (state) before continuing work, and must record the context when stopping. This context switching is analogous to the CPU switching between threads.

An operator can move between multiple lines (threads), which is concurrency. Multiple operators working on different lines simultaneously is parallelism. CPU‑bound tasks require little input (like a line that can run continuously), while I/O‑bound tasks spend most time waiting for input. Efficient scheduling assigns dedicated operators to CPU‑bound lines and lets operators handle I/O‑bound lines during idle periods.

2 Parallelism and Concurrency

A basic premise: a CPU can execute only one task at any instant.

Even on a single‑core machine, we perceive multiple tasks (e.g., listening to music while browsing) because the OS uses time‑slice round‑robin scheduling. Each process receives a time slice; when the slice expires, the OS preempts the process and schedules another, creating the illusion of simultaneous execution.

With multi‑core CPUs, true parallelism becomes possible, and the distinction between parallelism and concurrency becomes a common interview topic.

The process context includes the values of all CPU registers, the process state, and the contents of the stack. When the kernel switches to another process, it saves the current process’s context so it can be restored later.

3 Resources Shared by Threads

This section is excerpted from a Zhihu article titled “Code Island Survival for Programmers”.

“A process is the unit of resource allocation by the OS; a thread is the basic unit of scheduling, and threads share process resources.”

What resources are shared among threads, and how is this sharing implemented?

Thread‑private resources

When a function runs, its information is stored in a stack frame, which holds the return value, arguments, local variables, and register information. The program counter register indicates the next instruction to execute. Because the OS can pause a thread at any time, saving and restoring the program counter allows the thread to resume correctly.

Thus each thread has its own private stack area, program counter, stack pointer, and registers—collectively called the thread context.

Beyond these private parts, all other parts of the process address space are shared among threads.

Code segment

The code segment contains the compiled machine instructions loaded from the executable file. Since all threads share the same address space, any function can be executed by any thread.

Data segment

The data segment stores global variables. In C, a global variable is defined outside any function, e.g.:

All threads can read and write these global variables.

Heap segment

The heap holds dynamically allocated memory (e.g., via malloc or new in C/C++). Since the heap resides in the process’s address space, any thread that knows a pointer can access the allocated memory, making the heap a shared resource.

Thank you for reading, hope it helped :) Source: blog.csdn.net/mu_wind/article/details/124616643