Operating SystemsProcess Definition

Process Definition

LevelBeginner

Duration60 mins

TopicProcess Definition

2 / 5

Process as Execution Unit

The Operating System's Central Abstraction

Every operating system, from embedded microcontrollers to supercomputer clusters, revolves around one central concept: the process as the fundamental unit of execution.

This isn't a historical accident or arbitrary design choice. The process abstraction solves fundamental problems that arise when multiple programs must share finite hardware resources. Understanding why the process is the unit of execution—not the thread, not the application, not the machine code instruction—reveals deep truths about system design.

In this page, we explore the process not as a static definition, but as a living, managed entity that the operating system creates, schedules, protects, and ultimately destroys. The process is to the operating system what the cell is to biology: the basic unit of life and organization.

What You Will Learn

By the end of this page, you will understand why the OS treats processes as first-class citizens, how processes serve as containers for resource ownership, why process isolation is essential for system stability, and how the kernel's view of processes differs from the user's view.

The Need for an Execution Unit

Before we can appreciate the process abstraction, we must understand the problems it solves. Consider a world without processes—where programs run directly on hardware without OS mediation:

The Problems of Unmanaged Execution:

Chaos Without Processes

•No Memory Protection — Any program can read or write any memory location. A bug in one program corrupts another. Malware has unlimited access.
•No Resource Sharing — One program monopolizes the CPU. Others wait indefinitely. No fair allocation is possible.
•No Concurrent Execution — Only one program runs until completion. Users wait minutes or hours between tasks.
•No Cleanup on Failure — When a program crashes, its resources (open files, network connections) leak forever.
•No Accounting — No way to track which software uses how much CPU, memory, or I/O. Debugging performance is impossible.
•No Multi-User Support — Different users cannot run programs simultaneously without complete trust in each other.

The Process Abstraction Solves These Problems

The operating system introduces the process as a managed container for execution. Each process:

Lives in an isolated address space protected from other processes
Receives scheduled CPU time according to system policy
Owns resources (files, memory, sockets) tracked by the kernel
Can be terminated with guaranteed cleanup of all resources
Has an identity (PID, ownership) for accounting and access control

The process abstraction converts chaos into order, enabling the multitasking, multi-user systems that power modern computing.

The Container Analogy

Think of a process as a shipping container for code execution. Just as shipping containers standardized global trade by providing a uniform interface for transporting diverse cargo, processes standardize how the OS manages diverse software. The OS doesn't need to understand what a program does—it just manages the container.

What Makes the Process the Right Unit

Why is the process—rather than something larger like an 'application' or smaller like a 'function call'—the fundamental unit? The answer lies in what makes processes uniquely suitable for operating system management.

The Goldilocks Granularity:

Why Process is the Right Granularity
Alternative Unit	Problem if Used as Base Unit
Instruction	Too fine-grained. Billions of instructions per second. Impossible to track individually.
Function/Subroutine	Too fine-grained and too transient. Functions are called millions of times. No persistent state boundary.
Thread	Threads share address space—no isolation. Cannot be the fault boundary or security boundary.
Application	Too coarse-grained. Complex apps need subdivision. What about a browser with 50 tabs?
User	Too coarse-grained. One user runs many programs. Cannot isolate them from each other.
Process	Just right: isolated memory, tracked resources, killable unit, security boundary, schedulable entity.

The Process as a Natural Boundary:

A process represents a natural boundary for several critical concerns:

Process Boundaries

•Address Space Boundary — Each process has its own virtual address space. Pointers in one process are meaningless in another. This enables memory protection.
•Fault Boundary — When a process crashes, only that process is affected. Other processes continue unharmed. The system remains stable.
•Security Boundary — Processes run with specific permissions. A compromised process cannot directly access another's memory or resources.
•Resource Ownership Boundary — All resources a process acquires are tracked. When the process terminates, the OS reclaims everything.
•Scheduling Unit — The OS scheduler allocates CPU time to processes. Fine-grained scheduling at this level balances responsiveness and efficiency.

Threads Exist Within Processes

Threads are execution units within a process. They share the process's address space and resources, enabling efficient parallelism within a single application. But the process remains the fundamental unit for isolation, resource ownership, and protection. Threads are an optimization—processes are the foundation.

Process as Resource Container

One of the most important roles of a process is serving as a container for resource ownership. Every resource a running program uses—memory, open files, network connections, shared memory segments—is owned by and tracked within its process.

Resources Owned by a Process:

Resources Associated with a Process
Resource Type	Examples	Tracked In
Memory	Code pages, heap, stack, mmap regions	Page tables, mm_struct (Linux)
File Descriptors	Open files, pipes, sockets	File descriptor table
CPU State	Register contents, program counter	Saved when not running
Credentials	User ID, group ID, capabilities	Process credentials struct
Signal Handlers	Registered handlers, pending signals	Signal state structure
Limits	Max open files, max CPU time, max memory	Resource limits (rlimit)
Environment	Environment variables, command-line args	Process environment block
Working Directory	Current directory for relative paths	File system context

The Cleanup Guarantee:

When a process terminates—whether normally or abnormally—the operating system guarantees that all resources are reclaimed:

All open file descriptors are closed
All memory is returned to the system
Network connections are properly closed
Shared memory and semaphores are handled (reference counts decremented)
Child processes are reassigned to init/systemd
Locks held are released

This guarantee is fundamental. Without it, long-running systems would slowly leak resources until they crashed.

Observing process resources on Linux
Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# Examine resources owned by process 1234
$ ls -la /proc/1234/fd/          # Open file descriptors
$ cat /proc/1234/maps            # Memory mappings
$ cat /proc/1234/status          # Process status and limits
$ cat /proc/1234/limits          # Resource limits
$ cat /proc/1234/environ         # Environment variables (null-separated)
 
# Example output of /proc/1234/fd/ (file descriptors)
lrwx------ 1 user user 64 Jan 15 10:00 0 -> /dev/pts/0     # stdin
lrwx------ 1 user user 64 Jan 15 10:00 1 -> /dev/pts/0     # stdout
lrwx------ 1 user user 64 Jan 15 10:00 2 -> /dev/pts/0     # stderr
lr-x------ 1 user user 64 Jan 15 10:00 3 -> /etc/passwd    # open file
lrwx------ 1 user user 64 Jan 15 10:00 4 -> socket:[12345] # network socket
 
# When process 1234 terminates, ALL of these are automatically cleaned up

Resource Leaks Within Processes

While the OS guarantees cleanup when a process terminates, it doesn't prevent leaks during execution. A long-running process that continually allocates memory without freeing it will eventually exhaust available memory. This is a bug in the application, not the OS—but it's why long-running servers often have watchdog processes that restart them periodically.

The Kernel's View of a Process

From the kernel's perspective, a process is represented by a complex data structure that tracks everything the kernel needs to manage that process. In Linux, this is the task_struct—one of the largest and most important structures in the kernel.

Converting Mermaid diagram...

Key Components of the Process Descriptor:

•Process Identification — PID (process ID), TGID (thread group ID), UID/GID (user/group ownership), session ID, process group ID
•Process State — Current state (TASK_RUNNING, TASK_INTERRUPTIBLE, TASK_STOPPED, etc.)
•Scheduling Information — Priority, scheduling policy (SCHED_FIFO, SCHED_RR, SCHED_OTHER), time accounting
•Memory Management — Pointer to mm_struct (memory descriptor) containing page tables and virtual memory areas
•File System Information — Current working directory, root directory, open file table (files_struct)
•Signal Information — Pending signals, blocked signals, signal handlers
•CPU Context — Saved register contents (stored when process isn't running)
•Process Relationships — Pointers to parent, children, and sibling processes

Simplified task_struct (Linux 6.x)
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
// From include/linux/sched.h (heavily simplified)
// The actual structure is over 700 lines with hundreds of fields
 
struct task_struct {
    // State and flags
    unsigned int            state;          // TASK_RUNNING, etc.
    unsigned int            flags;          // PF_EXITING, PF_KTHREAD, etc.
    
    // Process identification
    pid_t                   pid;            // Process ID
    pid_t                   tgid;           // Thread group ID (same as pid for main thread)
    
    // Scheduling
    int                     prio;           // Dynamic priority
    int                     static_prio;    // Static priority (nice value based)
    unsigned int            policy;         // SCHED_NORMAL, SCHED_FIFO, SCHED_RR
    
    // Memory management
    struct mm_struct        *mm;            // Memory descriptor
    struct mm_struct        *active_mm;     // Active address space
    
    // File system
    struct fs_struct        *fs;            // Filesystem information
    struct files_struct     *files;         // Open file descriptors
    
    // Signal handling
    struct signal_struct    *signal;        // Signal handlers and state
    sigset_t                blocked;        // Blocked signals
    
    // Process hierarchy
    struct task_struct      *parent;        // Parent process
    struct list_head        children;       // List of children
    struct list_head        sibling;        // Linkage in parent's children list
    
    // CPU state (architecture-specific)
    struct thread_struct    thread;         // CPU registers, saved when not running
    
    // ... hundreds more fields for accounting, namespaces, cgroups, etc.
};

The Process Table

The kernel maintains a list of all processes in the system. On Linux, this is a linked list of task_struct structures. The scheduler iterates through runnable processes; signal delivery searches for target processes; and commands like 'ps' query this list. The /proc filesystem provides a user-space view of this information.

Process Identity: PIDs and Beyond

Every process in the system has a unique identity. The primary identifier is the Process ID (PID)—a positive integer assigned by the kernel when the process is created.

PID Characteristics:

•Unique at any given time — No two running processes share a PID
•Reused after termination — PIDs are recycled, but with delay to avoid confusion
•Sequential allocation — New processes typically get the next available PID
•Maximum value — Default max is 32768 on Linux (configurable up to 4 million)
•Reserved PIDs — PID 0 is the swapper/idle task; PID 1 is init/systemd

Process Identification Hierarchy
Identifier	Meaning	Scope
PID	Process Identifier	Unique identifier for the process
PPID	Parent Process ID	PID of the process that created this one
PGID	Process Group ID	Group of related processes (e.g., pipeline)
SID	Session ID	Login session; controls terminal
UID/EUID	User ID / Effective UID	Ownership for permissions
GID/EGID	Group ID / Effective GID	Group ownership for permissions
TGID	Thread Group ID	Same as PID for main thread; groups threads

Exploring process identity
Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# View current shell's identity
$ echo "PID: $$"
PID: 1234
 
# View parent's PID
$ echo "PPID: $PPID"
PPID: 1200
 
# Detailed view of a process's identity
$ ps -o pid,ppid,pgid,sid,uid,gid,comm -p $$
  PID  PPID  PGID   SID   UID   GID COMMAND
 1234  1200  1234  1234  1000  1000 bash
 
# Process groups: all processes in a pipeline share PGID
$ sleep 100 | grep foo | wc -l &
$ ps -o pid,pgid,comm | tail -5
  PID  PGID COMMAND
 1235  1235 sleep      # All share PGID 1235
 1236  1235 grep
 1237  1235 wc
 
# Sending signal to process group kills all three
$ kill -TERM -1235   # Negative PID = process group

PID Namespaces

Modern Linux supports PID namespaces—isolated views of process IDs. Inside a container, a process might see itself as PID 1, while from the host it might be PID 45000. This enables containers to believe they have their own init process while actually running on shared infrastructure.

The Process Hierarchy

Processes exist in a hierarchical relationship. Every process (except the first) is created by another process—its parent. This creates a tree structure rooted at the initial process (init or systemd on Linux, PID 1).

The Process Tree:

Converting Mermaid diagram...

Implications of the Hierarchy:

•Resource Inheritance — Children inherit many attributes from parents: environment variables, file descriptors, current directory, user/group IDs.
•Lifecycle Management — Parents are notified when children terminate. They must 'wait' for children to collect exit status.
•Orphan Handling — When a parent dies before its children, orphans are adopted by init/systemd (PID 1), which will collect their exit status.
•Process Groups — Hierarchies enable job control. Sending SIGTERM to a process group terminates an entire pipeline.
•Cgroup Hierarchies — Modern Linux extends this with cgroups, organizing processes into hierarchies for resource control.

Viewing the process tree
Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# View the full process tree
$ pstree
systemd─┬─ModemManager───2*[{ModemManager}]
        ├─NetworkManager───2*[{NetworkManager}]
        ├─sshd───sshd───sshd───bash───pstree
        ├─cron
        ├─dockerd─┬─containerd───8*[{containerd}]
        │         └─10*[{dockerd}]
        └─...
 
# Show PIDs in the tree
$ pstree -p
systemd(1)─┬─sshd(500)───sshd(1234)───sshd(1235)───bash(1236)───pstree(1250)
           ├─cron(600)
           └─dockerd(700)───containerd(800)─┬─container(850)
                                            └─container(900)
 
# Show a specific process and its ancestors
$ pstree -s -p 1250
systemd(1)───sshd(500)───sshd(1234)───bash(1236)───pstree(1250)

The Special Role of PID 1

PID 1 (init/systemd) is special: it cannot be killed (even by root with SIGKILL), it adopts orphaned processes, and if it terminates, the kernel panics. It's the ultimate ancestor and the last resort for process cleanup. Modern init systems like systemd have elaborate machinery to manage the process tree.

Process Isolation: The Foundation of Security

The process serves as the boundary of isolation—a protected domain that cannot be violated by other processes without explicit permission. This isolation is fundamental to system security and stability.

What Isolation Means:

Isolated (Protected)

•Memory — Each process has its own virtual address space
•File descriptors — Process A can't access Process B's open files
•Credentials — Each process has its own UID/GID
•Signal handling — Signals are per-process
•Environment — Each process has its own environment variables

Shared (Accessible)

•CPU — Time-sliced among all processes
•File system — Common namespace (with permissions)
•Network — Shared network stack (with per-socket isolation)
•Shared memory — Only with explicit setup
•Interprocess communication — Only through defined channels

Memory Isolation in Detail:

The most critical form of process isolation is memory isolation. Each process operates in its own virtual address space, completely separate from all other processes.

When Process A tries to access memory at address 0x7fff12345678, and Process B tries to access the same virtual address, they access completely different physical memory. The CPU's Memory Management Unit (MMU), configured by the OS, performs this translation using page tables unique to each process.

Demonstration of memory isolation
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
#include <stdio.h>
#include <unistd.h>
#include <sys/wait.h>
 
int global_var = 100;   // Shared at fork, then isolated
 
int main() {
    pid_t pid = fork();
    
    if (pid == 0) {
        // Child process
        global_var = 200;   // Modify in child
        printf("Child: global_var = %d (at %p)\n", 
               global_var, (void*)&global_var);
        sleep(1);
        printf("Child: global_var still = %d\n", global_var);
    } else {
        // Parent process
        sleep(0.5);
        printf("Parent: global_var = %d (at %p)\n", 
               global_var, (void*)&global_var);
        global_var = 300;   // Modify in parent
        printf("Parent: global_var now = %d\n", global_var);
        wait(NULL);
    }
    return 0;
}
 
/* Output:
Child: global_var = 200 (at 0x55a4b3b1c010)
Parent: global_var = 100 (at 0x55a4b3b1c010)   // SAME address, DIFFERENT values!
Parent: global_var now = 300
Child: global_var still = 200                  // Child's value unchanged by parent
*/

Isolation is Not Absolute

While processes are isolated by default, they can communicate through explicit channels: pipes, sockets, shared memory, files. Additionally, the kernel code running on behalf of a process has access to all memory. Root/administrator users can attach debuggers to processes, read their memory, and bypass isolation. Isolation protects against accidents and normal users, not against privileged attackers.

Summary: The Process as Execution Unit

We have explored why the process serves as the fundamental unit of execution in operating systems. Let's synthesize the key insights:

Key Takeaways

•The process abstraction enables multitasking — Without it, only one program could run, with no isolation or resource management.
•Processes have the right granularity — Not too fine (like instructions) or too coarse (like applications). Just right for resource ownership and protection.
•Processes are resource containers — All resources are owned by processes, enabling guaranteed cleanup on termination.
•The kernel tracks processes via descriptors — Complex structures (like task_struct) hold all state the OS needs.
•Each process has unique identity — PIDs, ownership, and hierarchical relationships organize the system.
•Processes form a hierarchy — Parent-child relationships organize resource inheritance and lifecycle management.
•Isolation is the foundation of security — Each process exists in a protected domain, especially regarding memory.

What's Next:

Now that we understand the process as the fundamental unit of execution, we'll explore how multiple instances of the same program can exist as separate processes. This capability is essential for servers, parallel processing, and the multi-user systems that power modern computing.

Page Complete

You now understand why operating systems center their design around the process abstraction. This foundation will help you reason about scheduling (which process runs?), memory management (how processes get memory), and protection (how processes are isolated).

2 / 5

Loading learning content...

Operating SystemsProcess Definition

Process Definition

LevelBeginner

Duration60 mins

TopicProcess Definition

2 / 5

Process as Execution Unit

The Operating System's Central Abstraction

Every operating system, from embedded microcontrollers to supercomputer clusters, revolves around one central concept: the process as the fundamental unit of execution.

What You Will Learn

The Need for an Execution Unit

Before we can appreciate the process abstraction, we must understand the problems it solves. Consider a world without processes—where programs run directly on hardware without OS mediation:

The Problems of Unmanaged Execution:

Chaos Without Processes

•No Memory Protection — Any program can read or write any memory location. A bug in one program corrupts another. Malware has unlimited access.
•No Resource Sharing — One program monopolizes the CPU. Others wait indefinitely. No fair allocation is possible.
•No Concurrent Execution — Only one program runs until completion. Users wait minutes or hours between tasks.
•No Cleanup on Failure — When a program crashes, its resources (open files, network connections) leak forever.
•No Accounting — No way to track which software uses how much CPU, memory, or I/O. Debugging performance is impossible.
•No Multi-User Support — Different users cannot run programs simultaneously without complete trust in each other.

The Process Abstraction Solves These Problems

The operating system introduces the process as a managed container for execution. Each process:

Lives in an isolated address space protected from other processes
Receives scheduled CPU time according to system policy
Owns resources (files, memory, sockets) tracked by the kernel
Can be terminated with guaranteed cleanup of all resources
Has an identity (PID, ownership) for accounting and access control

The process abstraction converts chaos into order, enabling the multitasking, multi-user systems that power modern computing.

The Container Analogy

What Makes the Process the Right Unit

The Goldilocks Granularity:

Why Process is the Right Granularity
Alternative Unit	Problem if Used as Base Unit
Instruction	Too fine-grained. Billions of instructions per second. Impossible to track individually.
Function/Subroutine	Too fine-grained and too transient. Functions are called millions of times. No persistent state boundary.
Thread	Threads share address space—no isolation. Cannot be the fault boundary or security boundary.
Application	Too coarse-grained. Complex apps need subdivision. What about a browser with 50 tabs?
User	Too coarse-grained. One user runs many programs. Cannot isolate them from each other.
Process	Just right: isolated memory, tracked resources, killable unit, security boundary, schedulable entity.

The Process as a Natural Boundary:

A process represents a natural boundary for several critical concerns:

Process Boundaries

•Address Space Boundary — Each process has its own virtual address space. Pointers in one process are meaningless in another. This enables memory protection.
•Fault Boundary — When a process crashes, only that process is affected. Other processes continue unharmed. The system remains stable.
•Security Boundary — Processes run with specific permissions. A compromised process cannot directly access another's memory or resources.
•Resource Ownership Boundary — All resources a process acquires are tracked. When the process terminates, the OS reclaims everything.
•Scheduling Unit — The OS scheduler allocates CPU time to processes. Fine-grained scheduling at this level balances responsiveness and efficiency.

Threads Exist Within Processes

Process as Resource Container

Resources Owned by a Process:

Resources Associated with a Process
Resource Type	Examples	Tracked In
Memory	Code pages, heap, stack, mmap regions	Page tables, mm_struct (Linux)
File Descriptors	Open files, pipes, sockets	File descriptor table
CPU State	Register contents, program counter	Saved when not running
Credentials	User ID, group ID, capabilities	Process credentials struct
Signal Handlers	Registered handlers, pending signals	Signal state structure
Limits	Max open files, max CPU time, max memory	Resource limits (rlimit)
Environment	Environment variables, command-line args	Process environment block
Working Directory	Current directory for relative paths	File system context

The Cleanup Guarantee:

When a process terminates—whether normally or abnormally—the operating system guarantees that all resources are reclaimed:

All open file descriptors are closed
All memory is returned to the system
Network connections are properly closed
Shared memory and semaphores are handled (reference counts decremented)
Child processes are reassigned to init/systemd
Locks held are released

This guarantee is fundamental. Without it, long-running systems would slowly leak resources until they crashed.

Observing process resources on Linux
Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# Examine resources owned by process 1234
$ ls -la /proc/1234/fd/          # Open file descriptors
$ cat /proc/1234/maps            # Memory mappings
$ cat /proc/1234/status          # Process status and limits
$ cat /proc/1234/limits          # Resource limits
$ cat /proc/1234/environ         # Environment variables (null-separated)
 
# Example output of /proc/1234/fd/ (file descriptors)
lrwx------ 1 user user 64 Jan 15 10:00 0 -> /dev/pts/0     # stdin
lrwx------ 1 user user 64 Jan 15 10:00 1 -> /dev/pts/0     # stdout
lrwx------ 1 user user 64 Jan 15 10:00 2 -> /dev/pts/0     # stderr
lr-x------ 1 user user 64 Jan 15 10:00 3 -> /etc/passwd    # open file
lrwx------ 1 user user 64 Jan 15 10:00 4 -> socket:[12345] # network socket
 
# When process 1234 terminates, ALL of these are automatically cleaned up

Resource Leaks Within Processes

The Kernel's View of a Process

Converting Mermaid diagram...

Key Components of the Process Descriptor:

•Process Identification — PID (process ID), TGID (thread group ID), UID/GID (user/group ownership), session ID, process group ID
•Process State — Current state (TASK_RUNNING, TASK_INTERRUPTIBLE, TASK_STOPPED, etc.)
•Scheduling Information — Priority, scheduling policy (SCHED_FIFO, SCHED_RR, SCHED_OTHER), time accounting
•Memory Management — Pointer to mm_struct (memory descriptor) containing page tables and virtual memory areas
•File System Information — Current working directory, root directory, open file table (files_struct)
•Signal Information — Pending signals, blocked signals, signal handlers
•CPU Context — Saved register contents (stored when process isn't running)
•Process Relationships — Pointers to parent, children, and sibling processes

Simplified task_struct (Linux 6.x)
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
// From include/linux/sched.h (heavily simplified)
// The actual structure is over 700 lines with hundreds of fields
 
struct task_struct {
    // State and flags
    unsigned int            state;          // TASK_RUNNING, etc.
    unsigned int            flags;          // PF_EXITING, PF_KTHREAD, etc.
    
    // Process identification
    pid_t                   pid;            // Process ID
    pid_t                   tgid;           // Thread group ID (same as pid for main thread)
    
    // Scheduling
    int                     prio;           // Dynamic priority
    int                     static_prio;    // Static priority (nice value based)
    unsigned int            policy;         // SCHED_NORMAL, SCHED_FIFO, SCHED_RR
    
    // Memory management
    struct mm_struct        *mm;            // Memory descriptor
    struct mm_struct        *active_mm;     // Active address space
    
    // File system
    struct fs_struct        *fs;            // Filesystem information
    struct files_struct     *files;         // Open file descriptors
    
    // Signal handling
    struct signal_struct    *signal;        // Signal handlers and state
    sigset_t                blocked;        // Blocked signals
    
    // Process hierarchy
    struct task_struct      *parent;        // Parent process
    struct list_head        children;       // List of children
    struct list_head        sibling;        // Linkage in parent's children list
    
    // CPU state (architecture-specific)
    struct thread_struct    thread;         // CPU registers, saved when not running
    
    // ... hundreds more fields for accounting, namespaces, cgroups, etc.
};

The Process Table

Process Identity: PIDs and Beyond

Every process in the system has a unique identity. The primary identifier is the Process ID (PID)—a positive integer assigned by the kernel when the process is created.

PID Characteristics:

•Unique at any given time — No two running processes share a PID
•Reused after termination — PIDs are recycled, but with delay to avoid confusion
•Sequential allocation — New processes typically get the next available PID
•Maximum value — Default max is 32768 on Linux (configurable up to 4 million)
•Reserved PIDs — PID 0 is the swapper/idle task; PID 1 is init/systemd

Process Identification Hierarchy
Identifier	Meaning	Scope
PID	Process Identifier	Unique identifier for the process
PPID	Parent Process ID	PID of the process that created this one
PGID	Process Group ID	Group of related processes (e.g., pipeline)
SID	Session ID	Login session; controls terminal
UID/EUID	User ID / Effective UID	Ownership for permissions
GID/EGID	Group ID / Effective GID	Group ownership for permissions
TGID	Thread Group ID	Same as PID for main thread; groups threads

Exploring process identity
Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# View current shell's identity
$ echo "PID: $$"
PID: 1234
 
# View parent's PID
$ echo "PPID: $PPID"
PPID: 1200
 
# Detailed view of a process's identity
$ ps -o pid,ppid,pgid,sid,uid,gid,comm -p $$
  PID  PPID  PGID   SID   UID   GID COMMAND
 1234  1200  1234  1234  1000  1000 bash
 
# Process groups: all processes in a pipeline share PGID
$ sleep 100 | grep foo | wc -l &
$ ps -o pid,pgid,comm | tail -5
  PID  PGID COMMAND
 1235  1235 sleep      # All share PGID 1235
 1236  1235 grep
 1237  1235 wc
 
# Sending signal to process group kills all three
$ kill -TERM -1235   # Negative PID = process group

PID Namespaces

The Process Hierarchy

The Process Tree:

Converting Mermaid diagram...

Implications of the Hierarchy:

•Resource Inheritance — Children inherit many attributes from parents: environment variables, file descriptors, current directory, user/group IDs.
•Lifecycle Management — Parents are notified when children terminate. They must 'wait' for children to collect exit status.
•Orphan Handling — When a parent dies before its children, orphans are adopted by init/systemd (PID 1), which will collect their exit status.
•Process Groups — Hierarchies enable job control. Sending SIGTERM to a process group terminates an entire pipeline.
•Cgroup Hierarchies — Modern Linux extends this with cgroups, organizing processes into hierarchies for resource control.

Viewing the process tree
Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# View the full process tree
$ pstree
systemd─┬─ModemManager───2*[{ModemManager}]
        ├─NetworkManager───2*[{NetworkManager}]
        ├─sshd───sshd───sshd───bash───pstree
        ├─cron
        ├─dockerd─┬─containerd───8*[{containerd}]
        │         └─10*[{dockerd}]
        └─...
 
# Show PIDs in the tree
$ pstree -p
systemd(1)─┬─sshd(500)───sshd(1234)───sshd(1235)───bash(1236)───pstree(1250)
           ├─cron(600)
           └─dockerd(700)───containerd(800)─┬─container(850)
                                            └─container(900)
 
# Show a specific process and its ancestors
$ pstree -s -p 1250
systemd(1)───sshd(500)───sshd(1234)───bash(1236)───pstree(1250)

The Special Role of PID 1

Process Isolation: The Foundation of Security

What Isolation Means:

Isolated (Protected)

•Memory — Each process has its own virtual address space
•File descriptors — Process A can't access Process B's open files
•Credentials — Each process has its own UID/GID
•Signal handling — Signals are per-process
•Environment — Each process has its own environment variables

Shared (Accessible)

•CPU — Time-sliced among all processes
•File system — Common namespace (with permissions)
•Network — Shared network stack (with per-socket isolation)
•Shared memory — Only with explicit setup
•Interprocess communication — Only through defined channels

Memory Isolation in Detail:

The most critical form of process isolation is memory isolation. Each process operates in its own virtual address space, completely separate from all other processes.

Demonstration of memory isolation
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
#include <stdio.h>
#include <unistd.h>
#include <sys/wait.h>
 
int global_var = 100;   // Shared at fork, then isolated
 
int main() {
    pid_t pid = fork();
    
    if (pid == 0) {
        // Child process
        global_var = 200;   // Modify in child
        printf("Child: global_var = %d (at %p)\n", 
               global_var, (void*)&global_var);
        sleep(1);
        printf("Child: global_var still = %d\n", global_var);
    } else {
        // Parent process
        sleep(0.5);
        printf("Parent: global_var = %d (at %p)\n", 
               global_var, (void*)&global_var);
        global_var = 300;   // Modify in parent
        printf("Parent: global_var now = %d\n", global_var);
        wait(NULL);
    }
    return 0;
}
 
/* Output:
Child: global_var = 200 (at 0x55a4b3b1c010)
Parent: global_var = 100 (at 0x55a4b3b1c010)   // SAME address, DIFFERENT values!
Parent: global_var now = 300
Child: global_var still = 200                  // Child's value unchanged by parent
*/

Isolation is Not Absolute

Summary: The Process as Execution Unit

We have explored why the process serves as the fundamental unit of execution in operating systems. Let's synthesize the key insights:

Key Takeaways

•The process abstraction enables multitasking — Without it, only one program could run, with no isolation or resource management.
•Processes have the right granularity — Not too fine (like instructions) or too coarse (like applications). Just right for resource ownership and protection.
•Processes are resource containers — All resources are owned by processes, enabling guaranteed cleanup on termination.
•The kernel tracks processes via descriptors — Complex structures (like task_struct) hold all state the OS needs.
•Each process has unique identity — PIDs, ownership, and hierarchical relationships organize the system.
•Processes form a hierarchy — Parent-child relationships organize resource inheritance and lifecycle management.
•Isolation is the foundation of security — Each process exists in a protected domain, especially regarding memory.

What's Next:

Page Complete

2 / 5