Foundations of Computer Systems & Operating System Architecture

An Operating System (OS) is specialized system software that acts as an intermediary between raw computer hardware (CPU, RAM, storage, I/O devices) and user-facing applications. Its fundamental mission is resource abstraction, resource allocation, concurrency control, and protection, providing a stable, efficient, and secure execution environment for programs.

1. Operating System Fundamentals: Roles, Functions, and Layers

Why Do We Need an Operating System?

Direct hardware manipulation requires interacting with raw physical memory addresses, disk sectors, and device registers. Without an OS, every application would require built-in device drivers and scheduling logic, creating security vulnerabilities, race conditions, and system crashes.

Real-Life Analogy

Think of computer hardware as a bustling restaurant kitchen and user applications as customers placing orders. If customers barged into the kitchen to grab pans and stoves directly, chaos and accidents would ensue. The Operating System acts as the Restaurant Manager/Head Chef: it receives orders, schedules which dish gets cooked on which burner (CPU scheduling), rations ingredients (RAM allocation), and prevents customers from interfering with each other (protection and security).

Core Functions of an Operating System

• Process Management: Creating, scheduling, synchronizing, and terminating processes while saving CPU states during transitions.
• Memory Management: Allocating and deallocating memory blocks, tracking occupied/free fragments, and mapping logical addresses to physical RAM.
• File Management: Organizing data into hierarchical trees, managing file permissions (read/write/execute), and handling directory namespaces.
• Device (I/O) Management: Interfacing with peripheral controllers through device drivers, buffering, caching, and Direct Memory Access (DMA).
• Protection and Security: Authenticating users, enforcing access control matrices, and isolating address spaces between processes.

2. Kernel Architecture and System Calls

The kernel is the foundational core of the OS that remains permanently resident in main memory. It operates in a privileged CPU state (Kernel Mode) to directly control hardware registers.

User Program (User Mode)
   |
   | 1. Executes privileged instruction / Request
   v
System Call Interface (Trap / Software Interrupt)
   |
   | 2. Switches CPU mode bit from User (1) to Kernel (0)
   v
Kernel Executes Service (Kernel Mode)
   |
   | 3. Completes hardware operation & resets mode bit to User (1)
   v
Returns Result to User Program

Kernel Architecture Paradigms

System Call Categories and Primitives

System calls serve as programmatic doors into the kernel:

• Process Control: fork() (spawns child process), exec() (replaces address space), wait(), exit().
• File Management: open(), read(), write(), close().
• Device Management: ioctl(), read(), write().
• Information Maintenance: getpid(), alarm(), sleep().
• Communication (IPC): pipe(), shmget(), socket().

3. Operating System Types: From Batch to RTOS

Operating systems have evolved to balance throughput, human interactivity, and hard latency deadlines.

• Batch OS: Jobs with similar requirements are batched offline and submitted without direct user interaction (e.g., IBM OS/360).
• Multiprogramming OS: Keeps multiple programs in memory simultaneously. When one job yields the CPU for I/O, the OS switches to another job, maximizing CPU utilization.
• Multitasking / Time-Sharing OS: An extension of multiprogramming where the CPU switches rapidly across processes using a fixed Time Quantum, creating the illusion of parallel execution for interactive users.
• Multiprocessing OS: Utilizes multiple physical CPUs/cores to achieve true hardware parallelism (Symmetric Multiprocessing - SMP).
• Real-Time Operating System (RTOS): Enforces deterministic response times.
  • Hard RTOS: Missing a deadline causes total system failure (e.g., Pacemakers, Aircraft Flight Control, Airbags).
  • Soft RTOS: Deadline misses degrade quality but do not cause fatal failure (e.g., Video Streaming, Live VoIP).
• Distributed & Embedded OS: Networks multiple autonomous nodes to appear as a single system (e.g., Hadoop clusters) or powers hardware-constrained embedded microcontrollers (e.g., FreeRTOS, Automotive ECUs).

4. Process Management, States, and Context Switching

Process vs. Program

A Program is a passive entity stored on disk as compiled executable code. A Process is an active entity—a program loaded into memory under active CPU execution, owning dedicated resources (RAM, file handles, registers).

The Process Control Block (PCB)

The PCB is a kernel data structure containing all metadata needed to pause and resume a process:

• PID (Process ID): Unique numerical identifier.
• Process State: Current operational phase.
• Program Counter (PC): Memory address of the next instruction to execute.
• CPU Registers: Accumulators, index registers, stack pointers.
• Memory Management Information: Page tables, segment descriptors.
• I/O Status Information: List of allocated devices and open file descriptors.

The 5-State Process Lifecycle Model

Context Switching Mechanics & Pure Overhead

Context switching is the procedure by which the CPU saves the operational state of a running process into its PCB and loads the saved PCB state of another ready process.

Pure Overhead: The CPU performs no useful computational work while executing the context switch logic (saving registers, swapping memory maps, invalidating Translation Lookaside Buffer caches). It is entirely administrative overhead.

5. Threads, Concurrency, and Multithreading Models

Process vs. Thread (Lightweight Process)

A Thread is the smallest schedulable unit of CPU execution within a process. Multiple threads under the same parent process share code, global data, and open file handles, but maintain independent thread execution contexts (Program Counter, CPU Registers, and Call Stack).

Comparison: Process vs. Thread

Multithreading Architectural Models

• Many-to-One (User-Level Threads - ULT):
  • Thread management handled entirely by a user-space runtime library.
  • Pitfall: If one user thread executes a blocking system call, the entire process blocks. Cannot utilize multi-core parallelism.
• One-to-One (Kernel-Level Threads - KLT):
  • Every user-level thread maps directly to an independent kernel thread (e.g., Linux, Modern Windows).
  • Advantage: True multi-core parallelism; a blocked thread does not stall other threads.
• Many-to-Many (Hybrid / Two-Level Model):
  • Multiplexes $M$ user threads over $N$ kernel threads ($M \ge N$). Provides balance but introduces scheduling complexity.

6. CPU Scheduling Algorithms and Metrics

CPU scheduling allocates CPU time slices to active processes in the Ready Queue, balancing responsiveness and throughput.

Key Performance Metrics

• CPU Utilization: Percentage of time the CPU is performing computation (Target: 40%–90%).
• Throughput: Number of completed processes per unit of time.
• Turnaround Time (TAT): $\text{Completion Time} - \text{Arrival Time}$.
• Waiting Time (WT): $\text{Turnaround Time} - \text{Burst Time}$. Total duration spent waiting in the ready queue.
• Response Time (RT): Time elapsed between process arrival and its first scheduled CPU burst.

Scheduling Paradigms & Algorithms

Algorithm Comparison Matrix

Conceptually: In Priority Scheduling, low-priority processes can remain in the Ready Queue indefinitely (Starvation). The standard mitigation is Aging—gradually incrementing the priority score of a waiting process proportional to its wait duration.

7. Process Synchronization and Concurrency Control

When concurrent threads or processes read and write shared memory locations, unpredictable execution interleavings cause inconsistent data states (Race Conditions).

The Critical Section Architecture

The Critical Section (CS) is the portion of code accessing shared resources. Any synchronization solution must satisfy three mandatory properties:

1. Mutual Exclusion: If process $P_i$ is executing in its CS, no other process can enter the CS.
2. Progress: If no process is in its CS, only processes wishing to enter can compete, avoiding deadlocks.
3. Bounded Waiting: There must be a limit on the number of times other processes enter their CS after a process requests entry, preventing starvation.

Synchronization Mechanisms

Peterson's Algorithm (2-Process Software Solution)

A software-level dual-flag mechanism satisfying all three properties for two processes:

// Process P_i structure
do {
    flag[i] = true;
    turn = j;
    while (flag[j] && turn == j); // Busy wait (Spinlock)

    // CRITICAL SECTION START
    shared_counter++;
    // CRITICAL SECTION END

    flag[i] = false;
    // Remainder Section
} while (true);

Mutex Lock vs. Counting Semaphore

Classical Synchronization Problems

• Producer-Consumer (Bounded-Buffer): Coordinated via three semaphores: mutex (mutual exclusion), empty (tracking buffer space), and full (tracking available items).
• Readers-Writers: Multiple readers can read simultaneously, but writers require exclusive, isolated access.
• Dining Philosophers: Models resource allocation deadlocks when five philosophers simultaneously acquire left chopsticks and wait indefinitely for right chopsticks.

8. Deadlock: Conditions, Prevention, Avoidance, and Recovery

A Deadlock is an execution stall where a set of processes are permanently blocked because every process holds a resource and waits for another resource held by another process in the set.

Coffman's Four Necessary Conditions

Deadlock can occur if and only if all four conditions hold simultaneously:

1. Mutual Exclusion: At least one resource is held in a non-shareable mode.
2. Hold and Wait: A process holds at least one resource while waiting to acquire additional resources held by others.
3. No Preemption: Resources cannot be forcefully confiscated; they must be released voluntarily by the holding process.
4. Circular Wait: A closed chain of processes exists: $P_0 \to P_1 \to P_2 \dots \to P_n \to P_0$.

Deadlock Handling Strategies

Deadlock Avoidance: The Banker's Algorithm

The Banker's Algorithm evaluates resource requests by verifying that granting them leaves the system in a Safe State—a state where at least one Safe Sequence $\langle P_1, P_2, \dots, P_n \rangle$ exists such that all processes can run to completion.

• Data Structures:
  • $\text{Available}[m]$: Available instances of resource $j$.
  • $\text{Max}[n][m]$: Maximum demand of process $i$ for resource $j$.
  • $\text{Allocation}[n][m]$: Currently allocated instances.
  • $\text{Need}[n][m] = \text{Max}[n][m] - \text{Allocation}[n][m]$.

9. Memory Management: Allocation, Paging, and Segmentation

Hierarchical Memory Architecture

Address Translation: Logical to Physical

The CPU produces a Logical Address during program execution. The hardware Memory Management Unit (MMU) translates this into a Physical Address in physical RAM.

Contiguous Allocation Pitfalls

• Internal Fragmentation: Allocated memory block is larger than the requested size; unused memory remains trapped inside the partition.
• External Fragmentation: Total free memory across the system is sufficient to satisfy a request, but storage is divided into small, non-contiguous holes.

Non-Contiguous Memory Architectures: Paging vs. Segmentation

10. Virtual Memory, Demand Paging, and Page Replacement

Virtual Memory decouples logical address spaces from physical RAM, allowing systems to execute processes whose combined working set exceeds physical memory capacity.

Demand Paging & The Page Fault Handler Workflow

Under demand paging, pages are brought from disk into RAM only when referenced.