Concurrency and parallelism are critical in building modern, scalable systems infrastructure. In this junior/senior-level class, we will take a deep dive into the fundamentals of concurrency and parallelism, including learning how concurrency works behind-the-scenes and techniques to write better, faster code.
In addition, this course will be taught mostly in Rust. Rust is a popular, modern programming language that focuses on memory safety without runtime overhead, making it perfect for tackling concurrent and parallel problems. No prior Rust experience is required; we will teach Rust as part of the curriculum. The course will focus on concurrent CPU programming, but many concepts apply to concurrent programming in other domains and devices such as GPUs.
This is the first offering of this course. As such, please bear with us as we tune the difficulty of the material correctly.
Topics include: problem partitioning, cooperative routines, parallel programming with threads, synchronization primitives in C, Rust intro, concurrency and parallelism in Rust, async/await, dataflow frameworks, cache coherency and memory consistency, and more.
The calendar page provides a detailed topic list for the course, including assignment dates. In addition, we are using Gitlab, Ed, Canvas, and Gradescope for various parts of the course.
Lectures are MWF at 10:30 in CSE2 G10. (Please double check all room assignments as they may change.) We may not publish all lecture recordings, so please plan to attend lecture in person.
Sections will largely focus on the homeworks and (unlike many CSE classes) you will need to attend to be able to complete the assignments. Similarly, sections will not be recorded, so plan to attend live.
All textbooks are optional.
mgiordan@cs.washington.edu
manfor@cs.washington.edu
olegian@cs.washington.edu
You can email the entire staff at
CSE493L-Staff@cs.washington.edu. However, you will likely receive a more reliable
response if you make a private post on Ed (see below).
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 also use email.
The homeworks are all programming projects. There are nine total. Every homework is to be done individually. All deadlines will be in Gradescope, and you will have at least a week to complete each homework.
The core of the course is to learn concurrency, parallelism, and Rust by building systems that incorporate these ideas. The first three assignments will be in C or C++, and will focus on concurrency and parallelism. Then, the next two assignments will be an introduction to Rust. Finally, the last four assignments will explore concurrency and parallelism within Rust.
The programming portion of each homework is autograded. We give you most of the test cases we run, but we reserve the right to add more test cases after the deadline. You have unlimited resubmissions until the late deadline.
Concurrent bugs are extremely difficult to debug. This is because they may only occur one in a thousand runs. This is very different from other CSE classes you may have taken. Please understand that it may take you a while to complete the assignments. Debugging concurrent systems by testing is extremely time consuming.
We strongly recommend you get an early start on the homeworks. See below for the late policy.
Homeworks will be distributed every Monday on Gitlab, and will be due two Wednesdays after (9 days per homework). Homeworks will be submitted by uploading a zip file to Gradescope.
Most homeworks will ask you to write and donate a test case. The purpose of this is twofold: one, you will get practice writing useful tests, and two, you will gain experience using the systems that you build. We specifically use the word "donate" because after the test case due date, all tests will be anonymized and released to all students. This will allow you to take advantage of everyone's creativity in order to ensure that you have a cohesive test suite.
Test cases will generally be due two days before the project deadline (on Mondays). There will be no late days for tests, since they need to be packaged and distributed immediately. We may also select some test cases to add to the autograding suite.
The test case that you write will be graded by a member of our staff. In particular, we are looking for interesting, unique use cases. Since every student is writing a test case, it may be more interesting for each test case to stress one element of the system in depth rather than lightly test all components. You are free to share tests before the test case deadline; however, you must share your test case publicly with the entire class or not at all. The test case grade will contribute to a portion of that homework's grade.
Every homework will come with a set of related questions. They are due at the same time as the homework code, with the same late policy. You can find them on Gradescope.
Each homework requires three submissions, which are weighed as follows. This is a rough outline. The exact percentages will differ for every assignment.
Here is the criteria for how we grade your style and test case:
In addition, roughly once a week there will be an in-class or in-section quiz. These quizzes are meant to be easy and not require studying, if you have attended lecture and done the assignments. They will be a few multiple-choice questions and take no longer than ten minutes. During lectures or section, we will provide warning for an upcoming quiz in the next lecture or section. They will be distributed online, so bring a laptop or phone.
Quizzes may be given during lecture or section, and will be announced the prior class. Your bottom two quizzes will be dropped.
The course will have a final exam. It will occur 8:30-10:20 am on Monday, Mar 16. It will cover material similar to the quizzes, and we do not expect it to be difficult for students who attend lecture and complete assignments honestly.
As the course is new, the grading scheme is still in flux. We expect to have the following ratio:
The mapping from percentage to a 4.0 scale will be determined at the end of the course. I do not believe in a "curve" with predefined ratios of 4.0s and 3.0s — I believe that everyone should be able to get a 4.0 in this course.
Our late policy is designed to give students maximal flexibility without having to ask us for permission in most cases, 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, please contact the staff or email the instructor. Often, we are able to work something out that is agreeable to everyone involved.
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 look at homework 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.
It is ok to use AI to ask generic questions, as long as you don't copy or paste any code to or from the chatbot.
All work is to be done individually. We take plagiarism extremely seriously.
Anonymous feedback can be sent to the instructor or TAs via feedback.cs.washington.edu.
This course is intended to eventually become CSE 334. As such, you may see references to 334 instead of 493L. We value your feedback immensely as we develop this course.