CS370: Operating Systems
CS370: Operating Systems |
|
| [Schedule] | [Assignments] | [Grading] | [Syllabus] | [Infospaces] | [Canvas] | [Home] |
Last updated on Monday, August 31, 2026 1:21 PM |
|||
| Professor | Lecture Coordinates | ||
Shrideep Pallickara |
|
||
| Key to Notation Readings will be from the Operating Systems Concepts book by Silberschatz, Galvin, and Gagne 10th edition. John Wiley & Sons, Inc. ISBN-13: 978-1119800361. [SCG] |
| Introduction | References and HW | ||
| This module provides an overview of the course, grading criteria, and a brief introduction to high level operating systems concepts. We will explore the differences between kernel mode and user-mode and why they exist. We will also look at the role the operating system plays between applications and the underlying hardware. | Ch {1,2} [SGG] Ch {1} [RR] Ch {1} [AT] Ch {1} AD |
||
Objectives:
|
|||
08/25 08/27 |
Lecture 1 Lecture 2 |
||
| Processes | Readings | ||
| Processes are a foundational construct in organizing computations within a system. This module will contrast differences between programs and processes. A key idea covered in this module is the notion of multiprogramming which can used to give the illusion that multiple processes are executing concurrently. We will explore the layout of processes in memory and the various pieces of metadata associated with a process that are maintained in a Process Control Block (PCB). The PCB plays a foundational role in how the OS context-swictches between different processes. There is quite a bit of bookkeeping involved in maintaining the illusion that everything is happening at once. | Ch {3} [SGG] Ch {2} [AT] Ch {2, 3} [RR] Ch {2, 3} [AD] |
||
Objectives:
|
|||
09/01 09/03 |
Lecture 3 |
||
| Inter-Process Communications | Readings | ||
| One of the operating system’s main jobs is to keep processes isolated, making sure they run independently without interfering with each other. But sometimes, isolation isn’t enough: processes need to communicate. In this module, we’ll explore how the OS makes that possible. We’ll break down the three key mechanisms that allow processes to exchange information while still maintaining order and control. Each IPC mechanism makes different trade-offs, and choosing between them is part of the problem rather than merely a matter of syntax. |
Ch {3} [SGG] Ch {2} [AT] Ch {2, 3} [AD] |
||
Objectives:
|
|||
09/08 09/10 |
|||
| Threads | |||
| Think of a thread as a lightweight unit of execution within a process: small, fast, and designed to coexist with other threads inside that process. But why would we want multiple units of execution inside one process? The main reason comes down to efficiency: simplified data sharing and rapid context switching. When multiple threads run inside the same process, they can share data easily, without the overhead that comes with communication between separate processes. Achieving this kind of seamless sharing across independent processes would be far more complex and much slower. Ultimately, threads give us a way to keep things both parallel and tightly connected, striking a balance between speed and coordination. As we will see, easy sharing is both their great advantage and the source of several interesting problems. |
Ch {4} [SCG] Ch {2} [AT] Ch {12} [RR] Ch {4} [AD] |
||
Objectives:
|
|||
09/15 09/17 |
|||
| Process Synchronization | Ch {5}[SCG] Ch {4} [AT] |
||
| When multiple processes (or threads) run at the same time and need to work together, they have to coordinate their actions carefully. The challenge isn’t just making them run concurrently: it’s making sure they do so correctly and safely. A flawed approach can lead to chaos, with processes stepping on each other’s toes in unpredictable ways. To get a deeper understanding of these challenges, we’ll explore some classic problems in synchronization. These time-tested scenarios reveal the fundamental issues that arise when processes share resources and need to stay in sync. Concurrency is one of those settings in which “almost correct” turns out to have a surprisingly precise technical meaning. |
|||
Objectives:
|
|||
09/22 09/24 09/29 |
|||
| Atomic Transcations | |||
| This module will cover issues relating to preserving atomicty of transcactions. We will explore issues that arise when a multiplicty of transcactions need to execute concurrently while preserving safety properties. The central question is this: how can operations run concurrently while still producing results that appear correct and orderly? | Ch {5}[SCG] |
||
Objectives:
|
|||
10/01 |
|||
Mid Term Exam (10/08): Covers all topics covered up until Thursday's (10/01) lecture. |
|||
| CPU Scheduling algoirithms | |||
| The kernel’s job isn’t just to run processes: it has to juggle them, making sure they all make progress without stepping on each other’s toes. The trick is in the scheduling. A good scheduling algorithm has to balance several competing goals: latency, throughput, priority, and fairness. No single approach is perfect, so we’ll explore a range of scheduling algorithms, each with its own strengths and trade-offs. Scheduling is less about finding the perfect algorithm than about deciding which imperfection we are willing to live with. | Ch {6} [SCG] Ch {7} [AD] Ch {2} [AT] |
||
Objectives:
|
|||
10/06 10/08 10/13 10/15 |
Mid Term Exam |
||
| Deadlocks | |||
| A large number of processes compete for limited resources on the machine. Incorrect synchronization between these competing processes can lead to deadlocks. In this module, we will look at how to characterize deadlocks and the various mechanisms we can use to prevent them by negating structural requirments necessary for deadlocks to occur. Note that everyone waiting politely for someone else to go first isn't a solution because nobody would. | Ch {7} [SCG] Ch {6} [AT] Ch {4} [AD] |
||
Objectives:
|
|||
10/20 10/22 |
|||
| Memory Management | |||
| Memory is a shared resource that must be effectively managed across different processes that are executing concurrently, Given that Instruction Set Architectures (ISA) operate on data stored in registers and memory, how memory is managed and shared across competing processes has implications for performance, including completion times and throughput. This module looks at how the OS turns a finite physical resource into a useful and protected abstraction for each process. | Ch {8} [SCG] Ch {3} [AT] Ch {9} [AD] |
||
Objectives:
|
|||
10/27 10/29 11/03 11/05 |
|||
| Virtual Memory | |||
| Pure paging-based memory allocation schemes can require processes to be entirely memory-resident. This is often infeasible and wasteful. In this module, we will explore algorithms that facilitate effective allocation of memory while minimizing wasteful allocations. We will also consider aspects of program behavior, such as the working set model, that reduce the total number of pages that need to be allocated to a process. Virtual memory is basically the OS promising more memory than it physically possesses and then working very hard to keep that promise respectable. | [Ch {9} [SCG] Ch {3} [AT] |
||
Objectives:
|
|||
11/10 11/12 |
|||
| Virtualization | |||
| Virtualization creates the illusion of multiple virtual machines on the same physical hardware. Virtualization allows a single computer to host multiple virtual machines, with each virtual machine potentially running a different operating system. As part of this module, we will look at Type-1 and Type-2 hypervisors and techniques for effective virtualization. We will also examine what the hardware and the OS must provide to make that illusion convincing. |
Ch {7} [AT] Ch {16} [SCG] Ch {10} [AD] |
||
Objectives:
|
|||
11/17 11/19 |
|||
| Containers | |||
| Containers are a lightweight, performant alternative to virtual machines. Unlike, virtual machines every container does not require its own full-blown OS. In fact, all containers on a single host share a single OS. In this module, we will see how a container is ultimately just a group of processes; a container can do what ordinary processes can do, subject to restrictions and isolation mechanisms enforced by the kernel. The abstraction may be lightweight, but the kernel is still doing the heavy lifting. | |||
Objectives:
|
|||
11/20 |
|||
Thanksgiving Break: Fall Recess at CSU November 21-29. |
|||
| File Systems | |||
| Data managed on a hard disk must be amenable to updates, discovery, and retrievals. The underlying storage system only deals with disk blocks. In this module we explore a foundational construct in file systems -- the file control block. We will explore how the design of the file control block informs efficiency in retrievals of content. We will round out our discussion of file systems with a look at the Unix File System, the File Allocation Table (FAT), and NTFS. A “file” may seem reassuringly simple from the user’s perspective; however, they do require a lot of machinery underneath. |
Ch {5} [AT] Ch {4} [RR] Ch {10, 11} [SCG] |
||
Objectives:
|
|||
12/01 12/03 |
|||
| Mass Storage | |||
| In this module, we will explore the technologies behind the two popular data storage frameworks: hard disk drives and solid state drives. We will explore the key enablers of these systems. In the case of solid-state drives we will explore issues such as write-amplifications, wear leveling, and read-disturb errors. These devices expose the same basic abstraction to the OS while behaving very differently underneath it. | Ch {11} [SCG] Ch {12} [AD] |
||
Objectives:
|
|||
12/08 |
|||
| Disk Scheduling Algorithms | |||
| In this module we will explore the rationale and need for disk scheduling algorithms. We will review several metrics that are used to assess the peformance of disk scheduling algorithms. We will explore and analyze several different disk scheduling algorthms. These algorithms are used to inform disk head movements as data are retrieved. We will look at the major approaches and the trade-offs each makes. |
Ch {12} [SCG] |
||
Objectives:
|
|||
12/10 |
|||
Comprehensive Final Exam in Natural Resources Room-140 Tuesday, December 15th, 6:20-8:20 pm |
|||
| Department of Computer Science, Colorado State University, Fort Collins, CO 80523 USA © 2026 Colorado State University |