Operating Systems — Course Companion Overview

The foundational idea of Week 3 is the distinction between a program and a process. A program is a passive artifact — an executable sitting on disk, inert until invoked. The moment the OS loads it into memory and begins executing it, it becomes a process: an active, stateful entity with its own private address space divided into four regions — the code (text) segment holding compiled instructions, the data segment for global and static variables, the heap for dynamically allocated memory, and the stack for function call frames and local variables. [OS Course Notes — Weeks 3 & 5.md]

The OS tracks every running process through a data structure called the PCB (Process Control Block), which stores the process state, program counter, CPU register values, memory management information, and a list of open files. The PCB is the OS's "dossier" on the process — everything needed to pause it and resume it later, which is exactly what happens during a context switch. A context switch saves the current process's PCB, loads the next process's PCB, and hands over the CPU. It produces no useful work and is considered pure overhead, which is why minimizing unnecessary switching is a real engineering concern. [OS Course Notes — Weeks 3 & 5.md]

Processes move through a well-defined lifecycle of five states. A newly created process starts in the new state, then moves to ready once it is in memory and waiting for CPU time. The CPU Scheduling mechanism picks it from the ready queue and transitions it to running. If the running process issues an I/O request or waits on an event, it moves to waiting (blocked); once that I/O completes it returns to ready. When execution finishes, the process reaches the terminated state. Understanding these transitions is essential both conceptually and for the exam, which frequently asks students to trace process state diagrams. [OS Course Notes — Weeks 3 & 5.md]

Where a process represents an isolated unit of computation with its own address space, a thread is a finer-grained unit of execution that lives *inside* a process and shares most of its memory. Specifically, all threads within a process share the code segment, data segment, and heap — but each thread maintains its own private stack and its own set of CPU registers (including the program counter). This distinction is fundamental: the stack is private because each thread has its own call history and local variables, while the heap is shared because threads often need to exchange data cheaply. [OS Course Notes — Weeks 3 & 5.md]

This sharing model makes threads significantly cheaper than processes to create and to switch between. The four headline benefits of multithreading are responsiveness (one thread keeps the UI alive while another does heavy computation), resource sharing (threads communicate through shared memory without needing heavyweight IPC mechanisms), economy (thread creation and context switching carry less overhead than the process equivalents), and multicore utilization (threads can run truly in parallel across CPU cores). [OS Course Notes — Weeks 3 & 5.md]

The cost of this shared memory model is synchronization complexity. Because threads can simultaneously read and write the same heap variables, concurrent execution without coordination produces race conditions — bugs where the outcome depends on the unpredictable interleaving of thread operations. Proper synchronization primitives (locks, semaphores, monitors) are required to prevent these errors, making concurrent programming significantly harder than single-threaded programming. The Key Concepts Glossary provides crisp definitions of race condition and related terms, and the Exam Prep — Midterm flags this as a key concept to understand before the midterm. [OS Course Notes — Weeks 3 & 5.md]

Week 5 pivots from *what* runs to *how* the OS decides who gets the CPU. CPU Scheduling is the OS mechanism that picks the next process (or thread) from the ready queue and grants it CPU time. The scheduler must balance five competing performance goals: maximize CPU utilization (keep the CPU busy as much as possible), maximize throughput (complete as many processes per unit time as possible), and minimize waiting time, response time, and turnaround time. These goals genuinely conflict with one another — a policy that maximizes throughput by favoring long batch jobs may devastate response time for interactive users — so every scheduling algorithm represents a deliberate trade-off. [OS Course Notes — Weeks 3 & 5.md]

The course covers four principal algorithms. FCFS (First-Come, First-Served) is the simplest: processes are served strictly in arrival order. Its weakness is the convoy effect, where a single long-running job at the head of the queue forces all shorter jobs behind it to wait, inflating average waiting time. SJF (Shortest-Job-First) avoids this by always serving the process with the shortest next CPU burst, yielding the theoretically optimal average waiting time — but it requires knowing (or predicting) burst lengths and risks starvation for long jobs if short ones keep arriving. Round Robin assigns each process a fixed time quantum and cycles through the ready queue, ensuring every process gets regular CPU time and making it well-suited to time-sharing systems; the risk is that a very small quantum causes excessive context-switch overhead. Priority Scheduling assigns a numeric priority to each process and serves the highest-priority one first, offering flexible control but again risking starvation for low-priority processes. The standard mitigation for starvation in priority scheduling is aging — gradually increasing the priority of waiting processes so that no job waits indefinitely. [OS Course Notes — Weeks 3 & 5.md]

A cross-cutting dimension that applies to all these algorithms is preemption. A non-preemptive scheduler lets a running process hold the CPU until it voluntarily yields (finishes or blocks on I/O). A preemptive scheduler can forcibly remove a running process — for example, when its time quantum expires (as in Round Robin) or when a higher-priority process arrives. Preemption enables much better responsiveness but requires careful handling of shared data to avoid inconsistencies. The Key Concepts Glossary has one-line definitions for all these terms, and the Exam Prep — Midterm highlights average-waiting-time calculations and Gantt chart construction as the most common question types on this material. [OS Course Notes — Weeks 3 & 5.md]

The three major themes of this course are not independent — they form a layered picture of how an operating system manages computation. Processes are the OS's primary unit of isolation and resource ownership; the PCB and state lifecycle give the OS the information it needs to manage them. Threads live inside processes and add concurrency at a finer granularity, trading isolation for efficiency. CPU Scheduling sits above both, orchestrating which process or thread actually runs at any given moment and making policy decisions that affect the responsiveness and fairness the user experiences. [OS Course Notes — Weeks 3 & 5.md]

The Key Concepts Glossary is the fastest way to solidify vocabulary across all three areas. The Exam Prep — Midterm page turns all of the above into a structured review checklist and practice questions targeted at the midterm scope (Weeks 3–5, including IPC). For the full structured course home with a clean topic index, see Course Overview — Operating Systems. All content traces back to OS Course Notes — Weeks 3 & 5.md. [OS Course Notes — Weeks 3 & 5.md]