Writing fast and scalable multi-core programs is hard. Multi-core programming models fail to abstract away the details of the underlying computer architecture, partly because of limitations in the hardware/software interfaces (such as instruction sets and memory models). We must thus understand the multi-core architecture, both to design efficient algorithms and systems, and to find better abstractions and interfaces.
This course covers the state of the art in multi-core programming and architecture. A main objective is to introduce students to open research problems in multi-core research.
NOTE: We will consider hardware only at the microarchitecture level, not at the logic/gate level; for an example of microarchitectural material, see the book A Primer on Memory Consistency and Cache Coherence.
Introduction (slides on moodle)
A Primer on Memory Consistency and Cache Coherence (Chapters 2, 6-8)
Optimistic concurrency control
Safe memory reclamation
Memory consistency models (hardware)
Memory consistency models (programming language)
Cache coherence protocols
Concurrency control in databases
Advanced issues in hardware transactional memory
Ordered parallelism and relaxed data structures (1/2)
Ordered parallelism and relaxed data structures (2/2)
Non-volatile memory and its relation to concurrency
The main requirement is for the project to make a new (even if small) contribution to our knowledge. You can try attacking a research problem shown in class, do something based on your own research, or implement and try to reproduce the results of prior papers.
The project may be done individually or in a group of 2 to 3.
Most projects will require programming, e.g., for experiments and evaluation. Programming language depends on the project, but projects reproducing prior work will likely be in C/C++.
Proposal: Submit a writeup (PDF, max 2 pages, in English) describing the problem, why it is interesting, the state of the art, and what you plan to do. Each group needs to submit only one copy (include the names and IDs of all members). We may need to iterate on the proposal; don't start working on the project before the proposal is approved.
Final report: Submit a writeup (PDF, English) describing the problem and what you did. Submit your code as well (preferably as a link to a repository on Github or Bitbucket). Unless otherwise agreed, your code must be runnable on the school's Linux machines. Each group needs to submit only one copy.