CS370: Operating Systems

[Schedule]

[Assignments]

Assignments

All assignments are due at 8:00 PM on the due date. There is a late penalty of 10% per-day for up to a maximum of 2 days. All assignments will be posted at least 2 weeks prior to its due date. We will have a mix of both written and programming assignments. All assignments will be posted on this page. No assignments will be accepted more than 4 days past the due date.

All assignments should be submitted using Canvas.

Required Use of Claude Code
You are required to use Claude Code for all assignments and to log that usage, but the goal is for you to leave the assignment understanding every line you submit, and not just produce working code by any means available.

	Release	Due Date
HW-0 [Optional]	7/21	None
HW1	8/24
HW2	29-Jan
HW3
HW4
HW5

Term Project	8/3


HW-Extra Credit [Optional]	2-Apr

Programming Exercise: Building a Memory-Safe Red-Black Tree in C Under Kernel-Style Constraints

A red-black tree is a data structure that keeps itself balanced, so that searches, insertions, and deletions all stay fast. You will build one. That is where the assignment begins, and it is the easy part.

Then the ground shifts. Again and again, the assignment changes the rules about where your tree's memory lives and how it may be reclaimed: allocations that fail halfway, memory drawn from a pool you wrote yourself, a stack too small to recurse on, two trees quietly sharing the same bytes. Each change mirrors a problem real operating systems face every day. Your tree must survive all of them while behaving, on the outside, exactly as before.

Additional details are available here.

Here's the companion walkthrough for the assignment.

Release date: July 21st

Assignment 1: A random number generator and probability distribution toolkit with built-in statistical testing

A pseudorandom number generator is just a deterministic function of a seed. The same seed always produces the same sequence. In this assignment you will build that function yourself, and then build a layer on top of it that reshapes a stream of uniform values into samples from named probability distributions: Bernoulli, binomial, geometric, exponential, normal, Poisson, and Zipf. The assignment also requires that you will implement goodness-of-fit tests (chi-squared and Kolmogorov–Smirnov) from their mathematical definitions, not just from from a statistics library.

Additional details coming soon.

Release date: August 24

Assignment 2: Writing a shell from scratch with support for arbitrary pipelined operators with support for shared memory

Assignment 3: Concurrency Control Using Threads

Assignment 4: Implementing and designing the Completely Fair Scheduler with a mix of Poisson and Zipf arrival processes

Term Project:A Device Someone Needs: Two Sensors, a Raspberry Pi, and Software You
Can Defend.

Forget the usual assignment format. This one hands you a person, not a spec. You'll find someone with a real problem, something a phone app can't quite solve, and build a device that actually solves it: a Raspberry Pi, at least two sensors, and software you wrote from scratch to run the show.

Here's the twist. Claude Code is required while you're building, but it's banned from what you ship. Every decision your device makes on its own, every detection, every diagnosis, has to be code you understand well enough to defend, out loud, by yourself. The agent can help you build the machine. It can't be the machine.

Why does this matter for an OS course? Because the interesting problems only show up when nobody's watching. Your device has to survive 3 a.m., alone, unattended, on the one day something actually happens. That's where processes, schedulers, interrupts, and IPC stop being lecture material and start being the reason your project works or doesn't.

You'll work in teams of two. There are 5 seed ideas to get you thinking (wellness monitoring, environmental coaching, security, predictive maintenance, and so on) but the best projects tend to wander off the list entirely! What doesn't budge is the evidence. Your system needs to run 48 hours unattended and prove it with logs. Your latency and reliability numbers need to be measurements, not vibes.

And here's the part people relax about too early: nobody expects perfection. Your budget is small, your sensors are cheap, things will break. What matters is what you did with what you had, and whether you can explain it honestly. The project ends with a live demo and an individual defense, so know your code. All of it. Even the parts that your teammate wrote.

Additional details are available here.

Extra Credit: Still thinking about this ...