Introduction

An operating system must support several applications and activities at the same time. Processes and threads are two fundamental abstractions used to organize this concurrent execution.

• A process is a running program environment with an independent virtual address space and operating-system-managed resources.
• A thread is an execution path within a process. Threads belonging to the same process share process resources while maintaining separate execution state.

Processes emphasize isolation and resource ownership. Threads emphasize concurrent execution and efficient sharing within one application.

In your System Design curriculum, this is Topic 2.2 under Computer Systems, Linux and Concurrency. The module uses processes, threads, synchronization, race conditions and deadlocks to establish local concurrency foundations before introducing distributed coordination.

Prerequisites

Program, Process and Thread

A process does not execute instructions without a thread. A newly created process normally begins with an initial thread and can create additional threads when concurrent execution is required.

What Is a Process?

A process is an operating-system-managed environment in which a program executes. It gives the running application a protected address space and access to assigned resources.

A process commonly contains:

• Virtual address space
• Executable code
• Global and static data
• Heap memory
• One or more thread stacks
• Open files and sockets
• Security identity and permissions
• Environment and runtime state
• At least one thread of execution

Simplified Process Model

Process
+---------------------------------------------+
| Virtual Address Space                       |
|                                             |
|  Executable Code                            |
|  Global and Static Data                     |
|  Heap                                       |
|                                             |
|  Thread 1 Stack    Thread 2 Stack            |
|  Thread 1 State    Thread 2 State            |
|                                             |
| Open Files, Sockets and Other Resources     |
+---------------------------------------------+

Process Identity

Operating systems assign a process identifier, commonly called a PID, to distinguish one process from another.

A process can also have relationships such as:

• Parent process
• Child process
• Process group
• Session
• Security or user identity

The exact process model and available relationships depend on the operating system.

Process Isolation

Separate processes normally have separate virtual address spaces. Ordinary memory writes performed by one process do not directly modify another process's private memory.

Process A                      Process B
+--------------------+         +--------------------+
| Address Space A    |         | Address Space B    |
|                    |         |                    |
| Global Data A      |         | Global Data B      |
| Heap A             |         | Heap B             |
| Thread Stack A     |         | Thread Stack B     |
+--------------------+         +--------------------+

Ordinary writable memory is isolated.

Isolation provides several benefits:

• A memory error is more likely to remain within one process boundary.
• Processes can run with different permissions.
• One process cannot normally read another process's private memory directly.
• Independent processes can be started, stopped or replaced separately.
• Process boundaries provide useful security and fault-isolation controls.

Process States

A process or its threads can move through operating-system scheduling states. Exact names vary, but a simplified lifecycle includes:

Created
   |
   v
Ready
   |
   v
Running
   |
   +----------> Waiting / Blocked
   |                  |
   |                  v
   +--------------- Ready
   |
   v
Terminated

What Is a Thread?

A thread is an independently schedulable sequence of instructions within a process.

Each thread normally has its own:

• Program counter
• CPU register state
• Stack
• Scheduling state
• Thread identifier
• Selected thread-local data

Threads in the same process commonly share:

• Executable code
• Global and static data
• Heap memory
• Process address space
• Open files and sockets
• Process-level configuration and identity

Multithreaded Process

One Process
+------------------------------------------------+
| Shared Code                                    |
| Shared Global Data                             |
| Shared Heap                                    |
| Shared Open Files and Sockets                  |
|                                                |
| Thread A          Thread B          Thread C    |
| +----------+      +----------+      +----------+|
| | Registers|      | Registers|      | Registers||
| | Counter  |      | Counter  |      | Counter  ||
| | Stack A  |      | Stack B  |      | Stack C  ||
| +----------+      +----------+      +----------+|
+------------------------------------------------+

Processes vs Threads

Inter-process Communication

Because processes normally have isolated address spaces, processes require an explicit communication mechanism.

Common IPC mechanisms include:

• Pipes
• Named pipes
• Sockets
• Shared memory
• Message queues
• Signals
• Files
• Operating-system-specific communication facilities

Pipe-based Flow

Process A
   |
   | Write bytes
   v
Operating-system Pipe
   |
   | Read bytes
   v
Process B

Socket-based Flow

Process A
   |
   | Serialize and send message
   v
Socket or Network Stack
   |
   | Receive and deserialize
   v
Process B

IPC requires a defined protocol, message format, error policy and ownership model. Shared memory can reduce copying, but shared updates still require synchronization.

Thread Communication

Threads can communicate through objects in their shared process memory.

Shared Queue
+---------------------------------------+
| Work Item 1 | Work Item 2 | Work Item 3 |
+---------------------------------------+
       ^                         |
       |                         v
 Producer Thread          Consumer Thread

Shared memory makes communication convenient, but unsynchronized access can produce:

• Race conditions
• Lost updates
• Inconsistent reads
• Memory-visibility defects
• Deadlocks
• Data corruption

Concurrency vs Parallelism

Single-core Concurrency

Time -------------------------------------------------->

CPU Core:
Thread A | Thread B | Thread A | Thread C | Thread B

The operating system rapidly switches among runnable threads. Tasks overlap in progress, but only one thread executes on the core at a given instant.

Multi-core Parallelism

Time -------------------------------------------------->

CPU Core 1:
Thread A | Thread A | Thread A | Thread A

CPU Core 2:
Thread B | Thread B | Thread B | Thread B

Different threads can execute simultaneously when separate cores are available and the operating system schedules the threads accordingly.

Context Switching

A context switch occurs when execution changes from one schedulable task to another.

The operating system may need to preserve or restore:

• Program counter
• CPU registers
• Stack pointer
• Scheduling information
• Memory-management context where applicable

Switching between threads in the same process can require less memory- management work than switching between separate processes, but actual cost depends on the operating system, processor and execution state.

Excessive switching can consume capacity through:

• Scheduling overhead
• Reduced cache locality
• Translation-cache disruption
• Lock handoff
• Interrupted instruction pipelines

Blocking

A thread blocks when it cannot continue until an event occurs.

Common blocking operations include:

• Waiting for file or network I/O
• Waiting for a lock
• Waiting for another thread
• Waiting on a condition variable
• Sleeping until a timer expires

Thread A:
Read from network
       |
       v
Waiting for data

Thread B:
Continues processing another task

With operating-system-managed threads, one blocked thread does not necessarily prevent another runnable thread in the same process from being scheduled.

POSIX Thread Example

The following example uses the POSIX threads interface. POSIX threads are not part of the ISO C standard.

#define _POSIX_C_SOURCE 200809L

#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>

struct ThreadInput
{
    int first;
    int last;
    long long result;
};

static void *sum_range(
    void *argument)
{
    struct ThreadInput *input =
        argument;

    input->result = 0;

    for (int value = input->first;
         value <= input->last;
         ++value) {

        input->result += value;
    }

    return NULL;
}

int main(void)
{
    struct ThreadInput first = {
        .first = 1,
        .last = 500000,
        .result = 0
    };

    struct ThreadInput second = {
        .first = 500001,
        .last = 1000000,
        .result = 0
    };

    pthread_t first_thread;
    pthread_t second_thread;

    int status =
        pthread_create(
            &first_thread,
            NULL,
            sum_range,
            &first
        );

    if (status != 0) {
        fprintf(
            stderr,
            "Unable to create "
            "the first thread.\n"
        );

        return EXIT_FAILURE;
    }

    status =
        pthread_create(
            &second_thread,
            NULL,
            sum_range,
            &second
        );

    if (status != 0) {
        pthread_join(
            first_thread,
            NULL
        );

        fprintf(
            stderr,
            "Unable to create "
            "the second thread.\n"
        );

        return EXIT_FAILURE;
    }

    if (pthread_join(
            first_thread,
            NULL) != 0) {

        return EXIT_FAILURE;
    }

    if (pthread_join(
            second_thread,
            NULL) != 0) {

        return EXIT_FAILURE;
    }

    long long total =
        first.result +
        second.result;

    printf(
        "Total: %lld\n",
        total
    );

    return EXIT_SUCCESS;
}

Compile on a POSIX Platform

cc -std=c17 -Wall -Wextra -Wpedantic -pthread thread_sum.c -o thread_sum

Program Analysis

1. Two independent work ranges are created.
2. Each thread receives a pointer to a different input structure.
3. The threads write to separate result fields.
4. pthread_join() waits for each thread to finish.
5. The main thread combines results only after both worker threads complete.
6. No two threads intentionally update the same result object.

Shared-data Race Example

static int counter = 0;

static void *increment_counter(
    void *argument)
{
    (void)argument;

    for (int index = 0;
         index < 100000;
         ++index) {

        ++counter;
    }

    return NULL;
}

The increment is a read-modify-write operation. Concurrent execution can cause lost updates, and the unsynchronized conflicting accesses produce a data race.

static int counter = 0;

static pthread_mutex_t counter_mutex =
    PTHREAD_MUTEX_INITIALIZER;

static void *increment_counter(
    void *argument)
{
    (void)argument;

    for (int index = 0;
         index < 100000;
         ++index) {

        if (pthread_mutex_lock(
                &counter_mutex) != 0) {

            return NULL;
        }

        ++counter;

        if (pthread_mutex_unlock(
                &counter_mutex) != 0) {

            return NULL;
        }
    }

    return NULL;
}

The mutex ensures that only one participating thread executes the protected update at a time. A production design should also define how synchronization failures are reported and whether a different aggregation approach reduces contention.

Linux Process Creation Example

The following example uses POSIX process interfaces and is not ISO C.

#define _POSIX_C_SOURCE 200809L

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <unistd.h>

int main(void)
{
    pid_t child =
        fork();

    if (child == -1) {
        perror(
            "fork"
        );

        return EXIT_FAILURE;
    }

    if (child == 0) {
        printf(
            "Child process: %ld\n",
            (long)getpid()
        );

        return EXIT_SUCCESS;
    }

    printf(
        "Parent process: %ld\n",
        (long)getpid()
    );

    int child_status;

    if (waitpid(
            child,
            &child_status,
            0) == -1) {

        perror(
            "waitpid"
        );

        return EXIT_FAILURE;
    }

    if (WIFEXITED(child_status)) {
        printf(
            "Child exit status: %d\n",
            WEXITSTATUS(
                child_status
            )
        );
    }

    return EXIT_SUCCESS;
}

Compile

cc -std=c17 -Wall -Wextra -Wpedantic process_example.c -o process_example

After fork(), both processes continue from the return point, but receive different return values. The child enters the child path, while the parent waits for the child through waitpid().

Process Memory After Creation

On systems implementing fork(), parent and child begin with logically separate process address spaces based on the parent's state. Implementations commonly avoid copying every memory page immediately by using copy-on-write techniques.

Immediately after fork:

Parent logical pages ----+
                         +---- Shared physical pages while unchanged
Child logical pages -----+

After one process writes:

Parent logical page ----------> Parent physical copy
Child logical page -----------> Child physical copy

Programs should rely on the documented process semantics rather than assuming one specific operating-system optimization.

Benefits of Multiple Processes

• Stronger memory isolation
• Independent permissions and identities
• Separate failure boundaries
• Independent deployment or restart
• Explicit communication contracts
• Ability to use different runtimes or implementations

Costs of Multiple Processes

• Separate address-space and resource overhead
• IPC design and serialization
• Additional data copying in some communication paths
• More complex lifecycle supervision
• Cross-process debugging and tracing
• Consistency challenges when state is duplicated

Benefits of Multiple Threads

• Efficient sharing of in-process data
• Concurrent request or task processing
• Parallel CPU execution on multiple cores
• Improved responsiveness when one thread waits for I/O
• Lower resource duplication than separate processes

Risks of Multiple Threads

• Race conditions
• Deadlocks
• Lock contention
• Memory-visibility problems
• Unsafe object lifetime
• Non-deterministic defects
• Process-wide impact from a fatal thread fault

Server Concurrency Models

Thread Pool

A thread pool creates a controlled number of worker threads and assigns queued tasks to those workers.

Incoming Work
      |
      v
Bounded Work Queue
      |
      +--------+--------+--------+
      |        |        |        |
      v        v        v        v
 Worker 1  Worker 2  Worker 3  Worker 4

A useful thread-pool design defines:

• Minimum and maximum worker count
• Queue capacity
• Admission and rejection policy
• Task cancellation
• Shutdown behaviour
• Exception or error handling
• Metrics for active workers and queue delay

Choosing Thread Count

There is no universal optimal thread count. The useful value depends on:

• Available CPU cores
• CPU-bound vs I/O-bound work
• Time spent waiting
• Memory available for stacks and task state
• Lock contention
• Connection-pool capacity
• Downstream service limits
• Required latency and throughput

CPU-bound workloads often gain limited benefit after available cores are occupied. I/O-bound workloads can use additional concurrency while some threads wait, but dependency and memory limits still apply.

Failure Isolation

Separate Processes

Process A fails
      |
      +--> Process A terminates

Process B
      |
      +--> Can continue if shared dependencies remain healthy

Threads in One Process

Thread A causes a fatal memory fault
      |
      v
Containing process can terminate
      |
      +--> Thread B terminates
      +--> Thread C terminates

Thread-level error handling can recover from ordinary task errors, but a fatal process-level memory or runtime failure can affect every thread in the process.

Shared State and Synchronization

Shared mutable state should be minimized and protected using an appropriate synchronization or ownership strategy.

Common approaches include:

• Mutexes
• Read-write locks
• Condition variables
• Semaphores
• Atomic operations
• Thread-local data
• Immutable data
• Message passing
• Single-owner state

The next course topics examine synchronization, race conditions and deadlocks in greater depth.

Linux Process and Thread Inspection

List Processes

ps -ef

Show Threads for a Process

ps -T -p PROCESS_ID

Interactive Thread View

top -H -p PROCESS_ID

Display Process Hierarchy

pstree -p

Inspect Process File Descriptors

ls -l /proc/PROCESS_ID/fd

Inspect Process Status

cat /proc/PROCESS_ID/status

Command availability and output can vary by Linux distribution, kernel and installed packages.

When to Prefer Processes

Processes are commonly considered when:

• Strong failure isolation is important
• Security permissions must differ
• Tasks use different runtimes
• Components need independent deployment or restart
• Shared-memory access should be limited
• An existing platform isolates workers by process
• Untrusted or unstable work requires containment

When to Prefer Threads

Threads are commonly considered when:

• Tasks need efficient access to shared in-process data
• One application performs several concurrent operations
• CPU work can run in parallel across cores
• I/O waiting should not block all application progress
• Process-level resource duplication would be undesirable
• A supported thread-safe runtime and library environment is available

Selection Questions

Common Mistakes

Recommended Test Cases

Best Practices

Practice Exercise

Design a file-processing application that reads several input files, transforms their records and writes one output file.

Tasks

1. Design a version using one process and one thread.
2. Design a version using one process and a bounded thread pool.
3. Design a version using several worker processes.
4. Identify which memory is shared in each design.
5. Identify the communication mechanism used by the process-based design.
6. Define who owns each input and output buffer.
7. Define how output ordering is preserved.
8. Define how worker failure is detected.
9. Define graceful shutdown behaviour.
10. Compare throughput, memory usage and failure isolation.

Model Comparison

Frequently Asked Questions