Important Dates
10/24: initial project proposal due
11/13: project check-in
12/5: project due
Overview
CS 554 will have a final project in place of a final exam. The goal of the project is to build on or apply the techniques of the class to a new theoretical or real-world example. Reasonable topics include:
- Hardware memory models
- defining
- proving equivalence
- applying to real hardware
- testing, or proving allowed behaviors of litmus tests
- using
herd - proving correctness of assembly programs
- Language memory models
- defining
- proving equivalence
- applying to real languages
- testing, or proving allowed behaviors of litmus tests
- using
CppMem - defining compilation schemes
- Program verification
- proving linearizability
- proving refinement
- program logics
- weak-memory data structures
Some possible project ideas include:
-
Formally define a memory model we haven’t talked about in class (operationally, axiomatically, or both), and give some examples of its use/prove some of its properties.
-
Run a range of litmus tests on a processor we haven’t discussed in class, and compare its results to those of known memory models.
-
Describe how the details of some specific processor architecture or language interact with its theoretical memory model (e.g., different types of fences or mixed-size accesses in x86, object operations in C++ or Java).
-
Prove correctness of a classic concurrent program (lock implementation, data structure, etc.) under one or more of the memory models we discussed, or analyze its flaws/assumptions if it does not work under some memory model.
-
If you know how to use some kind of theorem-proving software, write a machine-checked proof of one of the results from the class, or study an existing mechanized proof and report on its structure.
-
Try out a tool we didn’t use in class (RMEM, CDSChecker, RCMC, Alloy/TriCheck, Armada, etc.) and try to reproduce a result we discussed or prove the correctness of/find bugs in an interesting program.
If you’re interested in a more academic project, you might also find ideas in papers from conferences on programming languages (e.g. POPL), concurrency (e.g. CONCUR), and verification (e.g. CPP).
Project Proposal
To start, you (individually or as a group) should submit a one-or-two-page proposal that contains the following information:
- What you want to do, roughly speaking.
- Which models and/or tools you intend to use.
- A concrete example of the results you might produce (a sketch of a program graph, an example program, etc.).
- Anything else you’d like to mention, like the reason why you’re interested in this particular project, other possible sources of inspiration, or more things you’d like to add if you have time.
The purpose of this proposal is to get you started on thinking about the project, and to plan out a reasonable amount of work for it. If your proposal sounds too big or too small, we’ll discuss and figure out a way to resize it. If you’re having trouble picking a topic, come by office hours and we can talk about some possibilities.
Project Check-In
By the end of the day on 11/13, you should submit a short writeup of your progress so far, including any code, proofs, or documents you’ve written, and a description of one or more problems you’ve run into (whether you’ve solved them or not). You’ll receive credit as long as you’ve made any progress; this is an encouragement to start working on the project before the last minute, and an opportunity to get feedback and ask for help if you’ve gotten stuck on anything. (Of course, you can also always ask for help on Piazza or in office hours, and feel free to send me an in-progress project at any time.)
Final Project Submission
The project should be submitted by 11:59 PM on Friday 12/5. Your submission should include both the content of your project (code, paper formalisms, etc.) and a readme file (text, PDF, or similar) outlining the files included, describing what you set out to do and how much of it you accomplished, and highlighting any particularly interesting challenges or results.