Operating systems are responsible for (i) abstracting computer hardware into a more convenient programming interface for application developers, (ii) enforcing security and privacy, as well as fault isolation, between different users or programs sharing the same hardware, (iii) arbitrating resource usage between competing users and programs, and (iv) storing user data persistently so that it can be recovered even if the system crashes or the power goes out at an inconvenient moment.
They are also among the most complex pieces of software - concurrency and parallelism are inherent, operating system code needs to work correctly even (or especially) when applications are malicious, operating system reliability is often a key limiting factor in overall system reliability, and performance matters and is directly visible to users.
Many other applications, such as web browsers, databases, and cloud services, have to tackle similar issues to operating systems; the abstractions and ways of thinking are broadly applicable throughout computer science.
We believe the best way to learn the material is to implement the ideas presented in the course, and so there is a substantial programming project.
The calendar page provides a detailed topic list for the course, including readings, problem sets, and labs. In addition, we are using Gitlab, Ed, Canvas, and Gradescope for various parts of the course.
Lectures are MWF at 11:30 in CSE2 G01. (Please double check all room assignments as they may change.) We have set up the class for Panopto lecture capture. However, we encourage you to attend lecture in person, if at all possible.
Sections will largely focus on the labs and (unlike many CSE classes) you will need to attend to be able to complete the assignments. Sections are not Panopto captured - you must attend live. (Let us know if you are quarantined, and we will try to work something out.)
There is a final exam on Wednesday December 11 at 2:30pm.
tom@cs.washington.edu
nik0la@cs.washington.edu
ehaker1@cs.washington.edu
aniruk@cs.washington.edu
dstot@cs.washington.edu
The staff mailing list is cse451-staff@cs.washington.edu, but we would prefer that you use the discussion board whenever possible, eg, by making a private post.
The best way to contact the staff is to make a post on Ed. If your question is likely to be useful to other students, please consider making it public. (You can make the post "anonymous" to hide your identity from your classmates, but note that course staff can still see your identity on anonymous posts. See anonymous feedback at the very bottom of this page for submitting feedback without revealing your identity to course staff.) If your message is not relevant to other students or if it contains source code, make it private. We prefer you send messages via Ed if at all possible, because Ed lets us track whether we have handled the request. If you need to contact an individual staff member directly, you can use their email.
There are four kinds of assignments in this class, in addition to an end of term final exam. All deadlines will be in gradescope.
See the sections below for more information on each kind of assignment, as well as the sections on grading, the late policy, and academic honesty.
The core of the course is to extend a basic operating system kernel to support protected system calls, multiprocessing, extensible paged virtual memory, and a crash resilient writeable file system. The project is written in C, with a code base derived from the xv6 project developed for the MIT graduate operating systems course.
Labs are to be done with a partner. You may select a partner, or we will assign one randomly. You may also request to do the project by yourself, but we will only grant a limited number of those requests. After lab 1, each of the other labs is due every two to three weeks.
The labs are autograded, and that means you will need to come up with solutions that work in all cases. Except for the design document and questions, the labs are (for the most part) self-grading - we give you all of the test cases we run.
The best way to write code that works in all cases do this is to carefully think your design before writing any code. Design before code is especially important for operating systems where the number of possible code paths is exponential in the number of processes and threads, the cost of uncaught errors in production code is enormous, and it is often infeasible to catch every possible error through testing.
This is very different from other CSE classes you may have taken. If you think we are just saying that and we don't really mean it, please understand that it may take you as much as ten times as long to complete the assignments if you start writing code before you carefully think through the design with your partner. Debugging typos can be laborious but is a reality we all face. Debugging operating system design errors by testing is extremely time consuming.
We strongly recommend you get an early start on the labs. Many students underestimate the difficulty of the assignments, and leave themselves too little time to finish in time. The most common comment about the labs is that students wished they had gotten an earlier start. See below for the late policy.
To encourage you to design then code, we ask for a design document for labs 2-4, worth a sizeable portion of the total value of the lab, due a week in advance of the lab due date. The design document can be optionally revised and resubmitted with the lab for W credit (see below for details). You and your partner should agree on the design document before writing any code. Of course, you may find from time to time that you need to update the design, but you want to try to minimize that. You do not need to submit an updated design document with your solution, except if you are requesting W credit.
The specification for the design document varies for each lab; it can be found in the xk repo along with the lab descriptions. Please ensure that your name and your partner's name are included in the design doc, and that you mark in gradescope that the submission is from both of you.
There are optional revisions for the design doc, described below. These are only for students seeking W credit, and have no effect on anyone's grade (other than the W credit). They are to be submitted jointly with your partner, provided both of you are seeking W credit; if only one person in the team is seeking W credit, they should be submitted individually. Please mark in gradescope whether submitting design doc revisions singly or as a team.
Each lab (including lab 1) contains a set of implementation-specific questions based on the provided code and your solution. These are to be submitted in gradescope (there is a separate assignment for submitting the code and the answers to questions).
These also ask you to provide a short post-mortem for each lab: what worked for you, and what didn't.
For most lecture topics (which may span one or more class meetings), we will assign a problem set specific to that topic. These are to be completed individually.
The textbook is intended to complement the material covered in lecture and the labs, providing a more precise, complete, and in depth explanation of the course topics. Students who do the assigned reading will generally save time from having fewer design errors when doing the labs.
The class will be graded on an additive points system - that is, we plan to simply add up all of the points on the labs, problem sets, design reviews, and exam. We anticipate that the course will have roughly 1000 points, with about half of those from labs, lab design documents, and lab questions. The other half is roughly split between the problem sets and the final. That is, the final will be worth roughly 25% of the overall grade. If we assign fewer than 1000 available points, we will add any missing points as full credit to every student.
The course is not curved. Your grade on a 4.0 scale is computed by the following formula. \[ \min\left( \left.\left\lfloor\frac{\mathrm{(points+50)}}{20}\right\rfloor \middle/ 10 - 1.0 \right.,\ 4.0 \right) \] In other words, your grade will be computed by the following table:
| Points | Grade on 4.0 scale |
|---|---|
| ≥950 | 4.0 |
| ≥930 | 3.9 |
| ≥910 | 3.8 |
| ≥890 | 3.7 |
| ≥870 | 3.6 |
| ≥850 | 3.5 |
| ≥830 | 3.4 |
| ≥810 | 3.3 |
| ... | |
| ≥750 | 3.0 |
| ... | |
| ≥690 | 2.7 (grad sat) |
| ... | |
| ≥550 | 2.0 (undergrad sat) |
| ... |
This grading scheme may be somewhat unfamiliar to you. We will discuss it on the first day of lecture. Be sure you understand it, and feel free to ask any questions about it.
An important consequence the additive points-based grading scheme is that there is a sense in which every assignment is optional. If you are unable to complete some assignment, simply make sure to complete the remaining ones - we give you room to miss points and still get a good grade. For example, you can miss over 10% of the available points and still earn some form of an A grade.
Since you will receive the same number of points as your partner for your combined work on the labs, design documents, and lab questions, it is essential during partner-matching that you communicate expectations about your grade target. If you find yourself stuck in a situation where your partner wants to do significantly more or less work than you do, please contact the staff.
Most students find that they are able to complete all of the assignments to a high degree of quality, but that the assignments require a decent amount of effort. Students find the class time-consuming but rewarding, and so grades in this class are generally high.
If you are taking the class S/NS, note that per university policy, undergraduates receive S credit for any grade 2.0 or higher. Thus, an undergraduate would need to earn at least 550 points to receive S credit.
Our late policy is designed to give students maximal flexibility without having to ask us for permission, while still allowing us to grade assignments and get them back to students in a timely fashion. If you have an extenuating circumstance that causes you not to be able to complete the work on time, especially if due to something outside of your control (such as you or your lab partner has an illness), please contact the staff or email the instructor. Often, we are able to work something out that is agreeable to everyone involved.
Each kind of assignment has a separate late policy. Be sure you understand the differences. Contact course staff if you have any questions.
To turn in your lab after the 48 hour grace period, first check in your solution into gitlab and tag it as labx-final. Then contact the staff (eg via a private post on Edstem), providing both partner names. We will reopen gradescope by hand - the submission penalty will be taken as of the end of the day when you contact us (eg, even if we don't reopen until the next day, the penalty is computed as of the previous day) provided you make no further changes.
Lab 4 is due on December 9; there is no grace period and no credit is given for late submission.
Note that, unlike some other course policies you might be familiar with, in this class there is no cap on how much total grace time you can use over the quarter. You can use the grace period on every single problem set and lab (except the last one) and still get full credit.
The labs are difficult, and working with a partner can make things easier because you can discuss the details of your design together. Working with a partner is also a serious responsibility: your partner is relying on you to communicate and collaborate effectively. Do not agree to work with a partner if you are not willing to commit to these responsibilities.
A common misconception about working with a partner is that you should "split up the work". This is usually a terrible idea, especially in this class, because the hard part of the lab is the design process. It might take you multiple iterations to design your solution correctly, and all parts of the solution can depend heavily on all other parts of the solution, so there is no way to "split up" this design work. Instead, you should plan to pair program (i.e., work together synchronously) during the design process until you are confident that you have a correct design and have written the design document together. After that, you can either continue to pair program your implementation (we recommend this approach) or you can try to split up the implementation work. When in doubt, work together synchronously. When you do work separately, establish a clear communication channel and keep each other posted about where you are stuck.
To summarize, by entering a partnership, you are agreeing, at minimum, to:
We take the partner agreement extremely seriously and will enforce it. If you flagrantly and repeatedly abandon your partner, you can expect to take a zero on the lab regardless of how much work you put into it.
If your partner breaks this agreement, first try to communicate with them about it. If that doesn't work, contact the course staff.
Working with a partner is the default for this class. You may request a specific partner (as long as both of you agree), or you may request us to assign you a random partner. The partner form also allows you to request to work alone; we have the ability to support a small number of those requests.
When looking for a partner, be sure to communicate grade expectations. Also, if you plan to opt in to W credit, you should try to find a partner who wants W credit as well.
We are starting a pilot program to offer opt-in W credit for CSE 451.
All students, whether aiming to recieve W credit or not, will need to do a substantial amount of writing for this class (see above under design documents).
W credit in addition requires not only a substantial amount of writing, but also revision of that writing. Students who want W credit in 451 need to submit revised versions of their design documents for labs 2-4 (due dates on Gradescope). The revisions should take into account staff feedback on the design, and include any updates to the design that you encountered while implementing the lab. Revisions are generally due at the same time as the design doc for the subsequent lab; the lab 4 revision is due on Thursday of exam week.
Please read CSE's Academic Misconduct Policy.
You are encouraged to discuss all aspects of the course with and ask for help from the instructor, the TAs, and other students. However, do not cross this line: Do not share code or written text. Do not post solutions on the Internet, or code to Edstem except if it is in a private (not public) post. Do not look at lab or problem set solutions that might be on the Internet. Do not use someone else's code or text in your solutions or responses. Do not use any online AI tool to write your code. It is ok to share ideas, explain your code to someone to see if they know why it doesn't work, or to help someone else debug if they've run into a wall.
Some work in this class will be completed with a partner or group. The rest is to be done individually. We will clearly mark each piece of work as to whether it is to be done with your partner or individually. Please contact the staff if you are unsure about any part of how this policy applies to an assignment.
Anonymous feedback can be sent to the instructor or TAs via feedback.cs.washington.edu.