Threads, Multithreading Models, and IPC

Module Overview: This chapter bridges the gap between heavy process management and granular CPU execution. We explore how Context Switching incurs execution overhead, how Threads act as lightweight execution units sharing shared code and data, the differences between user-level and kernel-level threading, various Multithreading Models (Many-to-One, One-to-One, Many-to-Many), and the foundational principles of CPU Scheduling.

1. Context Switching and Pure Overhead

When an operating system transitions execution from one process ($P_1$) to another ($P_2$), it must save the current execution state (program counter, registers, memory maps) of $P_1$ and load the saved state of $P_2$.

• Pure Overhead: The extra CPU time spent managing these state saves and loads—time during which no actual user computation or application work is being accomplished.
• Contrast with Threads: Because process switching requires heavy kernel intervention and memory isolation reconfiguration, it is relatively slow. This motivates the design of lightweight execution units: Threads.

2. Core Mental Model: What is a Thread?

A Thread is the smallest unit of CPU execution within a process. While a process represents the heavyweight container (the running program with its allocated memory, open file descriptors, and security context), threads represent the individual execution paths running inside that container.

Real-Life Analogy: The Restaurant Kitchen

Imagine a Process as an entire Restaurant Building (it has a shared kitchen, shared ingredient storage, and a shared dining room address).

The Threads are the Individual Line Cooks working inside that kitchen.

• All cooks share the same pantry (Data / Files).
• All cooks follow the same master recipe book (Code).
• However, each cook has their own cutting board and knife set (Stack and Registers) to chop their specific vegetables independently.

Component Breakdown

A single process can house multiple threads ($T_1, T_2, T_3, \dots, T_n$).

• Shared Resources: Code, Global Data, Heap memory, and Open Files.
• Private Resources: Program Counter (PC), CPU Registers, and a dedicated Stack (for local variables and function call frames).

3. Process vs. Thread: Comprehensive Comparison

4. Types of Threads: ULT vs. KLT

Threads are managed at two distinct layers in an operating system architecture: User Space and Kernel Space.

A. User-Level Threads (ULT)

• Management: Implemented and managed by user-space thread libraries (e.g., POSIX pthreads, green threads) without kernel intervention.
• Performance: Extremely fast to create and schedule because no kernel mode switch is required.
• Limitation: The kernel is unaware of ULTs. If a single ULT performs a blocking system call (e.g., waiting for I/O), the entire process (and all its threads) is blocked.

B. Kernel-Level Threads (KLT)

• Management: Managed directly by the operating system kernel (e.g., Windows threads, Linux clone() based tasks).
• Performance: Slower to create and manage compared to ULTs due to system call overhead.
• Advantage: True parallelism. If one KLT blocks on I/O, the kernel can seamlessly schedule another KLT from the same or a different process on a separate CPU core.

5. Multithreading Models

To bridge user threads to kernel threads, modern operating systems adopt one of three primary mapping architectures.

6. Benefits of Multithreading

Adopting multithreading in application design yields four cardinal advantages:

1. Responsiveness: Keeps user interfaces active and interactive even while background tasks (such as network downloads, heavy computations, or file writes) are executing.
2. Resource Sharing: Threads naturally share the parent process's memory and resources without requiring complex IPC setups.
3. Economy: Creating and context-switching threads is significantly cheaper and faster than provisioning full-fledged processes.
4. Scalability: Multithreaded programs can readily scale across multiple CPU cores, executing distinct threads in parallel hardware pipelines.

7. Introduction to CPU Scheduling

Because multiple processes and threads compete for limited CPU cores, the operating system must decide which task gets the CPU next and for how long. This core subsystem is known as CPU Scheduling.

• The Scheduling Problem: When a process blocks for I/O or its time slice expires, the scheduler steps in to perform a context switch.
• Preemptive vs. Non-Preemptive:
  • Non-Preemptive (Cooperative): Once the CPU has been allocated to a process, the process keeps the CPU until it voluntarily terminates or switches to a waiting state.
  • Preemptive: The operating system can forcibly yank the CPU away from a running process when its time quantum expires or a higher-priority task arrives.

Summary and Key Takeaways

• Context Switching Overhead: Switching between processes consumes pure CPU overhead due to saving and restoring heavy state registers and memory maps.
• Threads as Lightweight Units: A thread is the smallest unit of CPU execution sharing code, data, and files with sibling threads within the same process.
• Memory & Isolation Trade-off: Threads share memory space for fast communication, but lack the crash isolation of independent processes (one bad thread can kill the entire process).
• ULT vs. KLT: User-Level Threads are managed in user space (fast, but one blocking call halts all), while Kernel-Level Threads are recognized by the OS, enabling true multi-core parallelism.
• Multithreading Models: Ranging from Many-to-One (blocking limitations) to One-to-One (modern OS standard) and Many-to-Many (flexible multiplexing).
• Multi-threading Benefits: Delivers high UI responsiveness, resource sharing economy, and hardware scalability across multi-core chips.
• CPU Scheduling Foundation: Decides process execution order and CPU allocation using preemptive or non-preemptive strategies to maximize throughput and system utilization.