A short note on how to write a review can be found here.
Some sanitized reviews I've written: one for a paper I
liked, one that I felt needed more work, and
one that I had some problems with.
Please e-mail your paper summaries to cse221@cs.ucsd.edu.
Remember that synopses are due before the lecture period in which
the paper is discussed.
CSE 221 Fall 2000
Operating Systems
Office: APM 4832
Phone: 534-3729
Email: marzullo@cs.ucsd.edu
Office Hours: Tuesday and Thursday 11:00-12:30 or by appointment.
Class: Tuesday and Thursday 2:20 - 3:40 in Peterson 103.
I read my e-mail fairly often, and so you may find sending me a message
to be the fastest way of getting an answer to a simple question or of setting
up a private meeting.
Course Objectives
The purpose of this course is to teach computer software system structures
from a design point of view. We will look at different structuring techniques,
and we will examine their usage in both important historical systems and
in modern systems.
In addition to learning about different system structures and different
operating systems, you should learn:
-
how to read a research paper in an objective manner;
-
how to write a review of a research paper;
-
how to do a literature search in a given system topic as the first step
of research.
Course Prerequisites
You need to have a good understanding of operating systems, such as one
gets from an undergraduate OS course. This course should have covered the
major subsystems such as multiprocessing, virtual memory, file systems,
communications. You should also have a good grounding in concurrency, the
basics of security, and in basic processor architecture.
Lectures
The class meets on Tuesdays and Thursdays in Peterson 103 from 2:20 to
3:40. Attendence of lectures is mandatory, since much of your grade will
be derived from your performance during this period. Over the course of
a quarter you can miss two lectures with no ill effect, but if you find
yourself needing to miss more, please discuss this with me.
The lectures in this class have a unusual format: I will be doing very
little of the talking. Instead, you will be expected to have read two papers
before each lecture (I will supply the papers). Read them carefully, because
I will ask questions about the paper and choose someone at random to answer
each questions. My role in the class is to direct the discussion rather
than to present the material in a digested format.
You will be asked to write a short (one or two paragraphs) summary of
each paper. This description should not just give a brief synopsis of the
paper. Instead, it shold explain what the paper attempted to demonstrate
and whether you believe that the authors were successful. Give concrete
reasons as to why you believe the authors were successful or not.
Grading
| In-class discussion: |
35% |
| Summaries: |
15%
|
| Reviews: |
20% |
| Project: |
30% |
| Total: |
100% |
Project
The project is due on 27 November 2000.
The goal of this project is to deepen your knowledge in one area of
computer systems research. Please form groups of three or four students
for this project.
I would like your group to identify a recent research paper (1996 or
later) in computer systems. After you have read the paper and cleared the
paper with me, construct a list of papers that are concerned with the topic
of the paper. You can start this list by looking at the references of the
paper, but you will most likely have to include some papers outside of
the transitive closure of the references.
Having compiled this list of papers (the list should contain six to
ten papers), read these papers in order to learn about the field of research
the original paper addressed and discuss the papers among yourselves (and
with me, if you wish).
You'll then be in a position to start the written part of your project.
Write a six-to-ten page paper based on your group's reading and discussion.
This paper can be structured in one of several ways:
-
You can write a survey paper that identifies the major research directions
in the area that you've identified. If you write such a paper, you should
attempt to both give a balanced presentation of the research that has gone
on in this field and you should end with your group's thoughts about fruitful
research directions in the area.
-
You can extend the original paper. This would be appropriate if the paper
solved only part of a large and somewhat theoretical problem. You might,
for example, propose some key experiments that would validate (or invalidate)
some assumptions made by the authors, or you might push a theoretical development
to a more realistic or a more broad set of system assumptions.
-
You can propose a novel direction of research. You should write such a
paper as a proposal for conducting research. This means that you should
summarize what has been done in the area, what question you propose to
answer, and why it is an important question to answer.
You can choose the original paper however you wish, but I would like you
to show me the paper first before proceeding.
You might consider choosing a topic from the research interests of the
systems faculty here. Here's a list of the faculty who do work in software
systems and a few words about their research interests. Feel free to approach
them directly for suggestions, or visit their web pages, or use MELVYL
to identify some of their recent papers, or come talk with me.
Reviews
I will distribute a paper that I will ask you to review. I will
distribute this paper in early November. At that time I will
have details on what I will expect to see in your review.