Principles of Computer Systems

Syllabus

Course Meeting Times

Lectures: 2 sessions / week, 1.5 hours / session

Lectures and handouts

Lectures are held twice per week, 1.5 hours a session (at least, we are starting there). Messrs. Lampson and Rinard will split the lectures. The tentative schedule is at the end of this handout.

The source material for this course is an extensive set of handouts. There are about 400 pages of topic handouts that take the place of a textbook; you will need to study them to do well in the course. Since we don’t want to simply repeat the written handouts in class, we will hand out the material for each lecture one week in advance. We expect you to read the day’s handouts before the class and come prepared to ask questions, discuss the material, or follow extensions of it or different ways of approaching the topic.

Seven research papers supplement the topic handouts. In addition there are 5 problem sets, and the project described below. Solutions for each problem set will be available shortly after the due date.

Current handouts will generally be available in lecture. If you miss any in lecture, you can obtain them afterwards from the course secretary.

Problem sets

There is a problem set approximately once a week for the first half of the course. Problem sets are handed out once a week in class and are due next week. They normally cover the material discussed in class during the week they are handed out. Delayed submission of the solutions will be penalized, and no solutions will be accepted after the due date.

Students in the class will be asked to help grade the problem sets. Each week a team of students will work with the TA to grade the week’s problems. This takes about 3-4 hours. Each student will probably only have to do it once during the term.

We will try to return the graded problem sets, with solutions, within a week after their due date.

Policy on collaboration:

We encourage discussion of the issues in the lectures, readings, and problem sets. However, if you collaborate on problem sets, you must tell us who your collaborators are. And in any case, you must write up all solutions on your own.

Projects

During the last half of the course there is a project in which students will work in groups of three or so to apply the methods of the course to their own research projects. Each group will pick a real system, preferably one that some member of the group is actually working on but possibly one from a published paper or from someone else’s research, and write:

A specification for it.

High-level code that captures the novel or tricky aspects of the actual implementation.

The abstraction function and key invariants for the correctness of the code. This is not optional; if you can’t write these things down, you don’t understand what you are doing.

Depending on the difficulty of the specification and code, the group may also write a correctness proof for the code.

Projects may range in style from fairly formal, like handout 18 on consensus, in which the ‘real system’ is a simple one, to fairly informal (at least by the standards of this course), like the section on copying file systems in handout 7. These two handouts, along with the ones on naming, sequential transactions, concurrent transactions, and caching, are examples of the appropriate size and possible styles of a project.

The result of the project should be a write-up, in the style of one of these handouts. During the last two weeks of the course, each group will give a 25-minute presentation of its results. We have allocated four class periods for these presentations, which means that there will be twelve or fewer groups.

The projects will have five milestones. The purpose of these milestones is not to assign grades, but to make it possible for the instructors to keep track of how the projects are going and give everyone the best possible chance of a successful project

1. We will form the groups around day 8, to give most of the people that will drop the course a chance to do so.
2. Each group will write up a 2-3 page project proposal, present it to one of the instructors around spring break, and get feedback about how appropriate the project is and suggestions on how to carry it out. Any project that seems to be seriously off the rails will have a second proposal meeting a week later.
3. Each group will submit a 5-10 page interim report in the middle of the project period.
4. Each group will give a presentation to the class during the last two weeks of classes.
5. Each group will submit a final report on the last day allowed by MIT regulations. Of course you are free to submit it early.

Half the groups will be ‘early’ ones; the other half will be ‘late’ ones that give their presentations one week later. The due dates of proposals and interim reports will be spread out over two weeks in the same way. See the schedule later in this handout for precise dates.

Grades

There are no exams. Grades are based 30% on the problem sets, 50% on the project, and 20% on class participation and quality and promptness of grading.