Introduction
Threads are often described as sharing memory, but the complete idea is slightly more specific. Threads inside the same process share the process environment, not every part of their execution.
This distinction matters because it explains both the speed and the risk of multithreading. Shared memory makes communication faster, but it also means two threads can accidentally modify the same data at the same time.
Core Idea
A process owns the main memory environment, and threads run inside that environment. So threads do not get separate process memory spaces like independent processes do.
The shared part helps threads communicate easily. The private part helps each thread continue its own function calls, instructions, and CPU work independently.
Memory Shared Between Threads
Anything that belongs to the process is generally visible to all threads in that process. This includes the major memory segments and many process-level resources.
Shared part | Meaning |
|---|---|
Code segment | Contains the executable instructions of the program |
Data segment | Stores initialized global and static variables |
BSS segment | Stores uninitialized global and static variables |
Heap | Stores dynamically allocated memory |
Memory-mapped regions | Includes mapped files or shared mappings |
File descriptors | Open files and I/O resources used by the process |
Process credentials and limits | Permissions, identity, and resource limits of the process |
Heap memory is especially important. Even if one thread allocates memory dynamically, another thread can access it if it has a valid pointer to that memory.
Memory Shared Between Threads
State Private to Each Thread
Each thread has its own execution state. This does not mean the thread has its own full address space; it only means the thread has private information needed to continue its current execution.
Private part | Meaning |
|---|---|
Stack | Stores function calls, return addresses, and local variables |
Program counter | Stores the next instruction the thread will execute |
CPU registers | Store the current working values of that thread |
Thread ID | Identifies the thread separately |
Scheduling state | Helps the OS schedule and track the thread |
This is why two threads can execute different functions at the same time. They share the same process memory, but each thread has its own stack and CPU execution context.
State Private to Each Thread
Simple Example
Suppose a process has a global variable counter = 0. Thread A has a local variable x = 10, and Thread B has a local variable y = 20.
counter: shared because it is a global variable in process memory.
x: private to Thread A because it is normally stored on Thread A’s stack.
y: private to Thread B because it is normally stored on Thread B’s stack.
Both threads can read and update counter. If they update it at the wrong time without synchronization, the final value may become incorrect. This is where race conditions begin.
Process vs Thread Memory
A process is mainly a resource-owning unit. It has its own address space, memory layout, open files, and other process-level resources.
A thread is mainly an execution unit inside a process. It shares the process resources but keeps its own stack, registers, program counter, and scheduling details.
Summary
Threads in the same process share the process environment, including code, global variables, heap memory, data segments, BSS, memory-mapped regions, file descriptors, credentials, and resource limits.
Each thread keeps its own execution state, including stack, program counter, CPU registers, thread ID, and scheduling state. The clean rule is: process memory is shared, but each thread’s execution state is private.
Be the first to add a comment.