Operating Systems
In industry the operating system has become the containment layer for AI: agent tool calls and machine-generated code are confined with namespaces, control groups, and system-call filters, while schedulers, paging, and I/O paths are tuned for accelerator-bound inference. The course therefore keeps its virtualization, concurrency, and persistence core intact and adds least-privilege confinement of agent workloads plus disciplined verification of AI-authored systems code.
Current catalog prerequisites — (CSC 250 or 2050).
Current description → proposed description
This course examines the foundational concepts, functions, and structure of operating systems. The primary operating system responsibilities of supporting virtualization, concurrency, and persistence are studied in depth. Students will investigate key concepts via a number of interactive simulations. In addition, students will carry out a number of systems programming projects in order to gain hands-on experience.
Prerequisites: (CSC 250 or 2050).
This course examines the foundational concepts, functions, and structure of operating systems, studying in depth the primary responsibilities of virtualization, concurrency, and persistence. Students analyze process abstraction, system calls, and context switching; compare CPU scheduling policies and their trade-offs among throughput, latency, and fairness; implement address translation, demand paging, and page replacement; build concurrent programs with threads, locks, condition variables, and semaphores; and examine file system layout, journaling, and crash consistency, working through interactive simulations and a sequence of hands-on systems programming projects. The course then treats the operating system as the boundary that contains untrusted and machine-generated code: students apply namespaces, control groups, system-call filtering, and least-privilege capabilities to confine tool-calling AI agents within a justified resource budget, and measure how scheduling and paging shape inference latency and cost. Because coding agents are now routinely used to produce systems code, students also review machine-generated concurrency and system-call code with sanitizers and deterministic stress testing, remaining accountable for behavior they did not personally write.
What changes
- Retains the virtualization, concurrency, and persistence core and adds scheduling, synchronization, and file-system implementation detail
- Least-privilege confinement of tool-calling agent workloads, justified against policy and consent constraints
- Measurement of how scheduling and paging behavior differs for model-inference workloads
- Review and verification of AI-generated concurrency and system-call code
- Crash consistency framed around audit and provenance data
5 proposed outcomes, mapped to 8 program outcomes
Each outcome below is written to be observable and assessable, and each is mapped to the program learning outcomes for which it produces evidence.
Students will be able to analyze how an operating system virtualizes the CPU and memory through process abstraction, scheduling policy, address translation, and demand paging, using measured latency, throughput, and fairness data to characterize how memory-intensive model inference differs from classical CPU-bound and I/O-bound workloads under the same policies.
PLO 6.1: students must interpret and explain measurement outcomes from instrumented runs, including what those outcomes mean for AI workloads, rather than only describe mechanisms. PLO 6.2: the required conclusion is a quantitative characterization of how the model-inference workload class behaves differently from CPU-bound and I/O-bound work under identical scheduling and paging policies, so the analysis is of an AI workload pattern rather than of a benchmark label.
Students will be able to implement concurrent systems programs using threads, locks, condition variables, and semaphores that are demonstrably free of data races and deadlock under deterministic stress testing and dynamic analysis tooling, and document each failure diagnosed, the revision it prompted, and what it changed in their own debugging approach.
PLO 4.3: the required record of each diagnosed failure, the revision it prompted, and the resulting change to the student's own debugging approach is an assessable self-reflection deliverable that continuously assesses and improves their problem-solving method, not an inference drawn from a working program.
Students will be able to evaluate the crash-consistency and durability guarantees of file system designs, including journaling, copy-on-write, and fsync discipline, under injected failure conditions that threaten audit and provenance records written by automated processes.
PLO 6.1: students must interpret recovery-experiment results and explain what a storage layer does and does not guarantee to the pipelines and audit trails that depend on its data. PLO 4.1: judging which durability guarantee is adequate for data whose silent loss would propagate into downstream AI training and audit records is critical analysis of a data-driven outcome with consequences beyond the machine.
Students will be able to construct an operating-system-enforced isolation boundary using namespaces, control groups, system-call filtering, and capability restriction or a lightweight virtual machine that confines a tool-calling AI agent and the code it generates to a least-privilege system-call, filesystem, and resource budget, and justify that budget in writing against a stated organizational policy, legal, or user-consent constraint.
PLO 3.2: the written justification requires students to bring policy, legal, and user-consent reasoning from outside computer science to bear on what an agent acting on a user's behalf may do, and to communicate that reasoning, which is the interdisciplinary work of developing a human-centered AI application. PLO 2.3: capping an agent process's CPU, memory, and I/O and denying it unnecessary privilege is concrete, responsible management of shared computing resources.
Students will be able to critique systems code generated by an AI coding agent for race conditions, memory-safety violations, and incorrect system-call and error handling, justifying an accept, revise, or reject decision with reproducible evidence and articulating why responsibility for machine-generated behavior remains the engineer's own under a Christian understanding of vocation and stewardship.
PLO 1.2: students must articulate, not merely assume, why a Christian understanding of vocation and stewardship places accountability for machine-generated behavior on the engineer, which is the reflection on how Christian values guide accountability that this PLO names. PLO 5.1: the accept, revise, or reject decision must be defended in writing with reproducible evidence, which is transparent technical communication delivered with integrity.
Program outcomes this course reaches
Filled cells are program learning outcomes with at least one supporting course learning outcome in this course. Sparse coverage is expected — no single course carries all eighteen.