CS372: Introduction to Operating Systems
Fall 2000

The crosscutting theme in this course is providing abstractions above imperfect hardware to make it usable by programmers and users. At the end of the course, students should understand a set of abstractions (concurrent programming, virtual addressing, memory protection, caching, transactions, ...) that are useful in many large-scale software systems not just OS kernels. More important than memorizing specific abstractions used in operating systems of the past, students should understand these abstractions well enough to synthesize their own abstractions when faced with new problems.

Another important goal of the course is for students to understand the computers they use and on which they build their applications. A student graduating with a CS degree should believe "there is no magic": they should be able to describe the chain of events that occurs when they hit a key and cause a letter to appear on the screen from the register level (or logical gate level or transistor level) to the system architecture level to the operating system level to the application level. This is philosophically important, but it is also of practical interest to developers who need to figure out how to make a system do what they want it to do.

Old Announcements

Administrative Information

Instructors:	Mike Dahlin (dahlin@cs.utexas.edu) 471-9549	Lorenzo Alvisi (lorenzo@cs.utexas.edu) 471-9792
Office Hr/#:	TTh 4:00 - 5:00 PM, ACES 6.248	TTh 4:00 - 5:00 PM, ACES 6.244
Class Info:	51293   TTh 5:00 - 6:30, TAY 2.106	51287   TTh 2:00 - 3:30, TAY 2.106
TAs:	Fengteng Tu (ftu@cs.utexas.edu) Office TBA	Stefano Masiui (stefano@cs.utexas.edu) Office hrs: Wed, Fri 10:00-11:00AM Location: PAI 5.40B   Phone: 232-7872
Newsgroup:	utexas.class.cs372
Home page:	http://www.cs.utexas.edu/users/dahlin/Classes/UGOS/index.html This handout and all other information for the course will be available at this address.
College of Natural Sciences policies

Readings

• Silbershatz Operating Systems Concepts, 5th edition

 
• Optional:Stroustrup The C++ Programming Language

Grading and Course Mechanics

That said, grades will be determined as follows:

• Midterm 1: 15%
• Midterm 2: 25%
• Problem sets: 10%
• Projects: 50%

I grade on a curve rather than an absolute scale because it protects students from stressing out if I happen to give an overly hard midterm or final. The downside of grading on a curve is that it tends to lead students to think they are competing against each other. In practice, this is mistaken in a class this large. The largest impact any individual student's performance is likely to have on your grade is less than 0.1% -- in other words, well into the noise.

Also, for this type of project students often stress about whether they will be penalized because their project may not be as elaborate as that of some of the other groups in the class. Again, this is a myth. The project is hard enough without looking over your shoulder at other students. By and large, most students do quite well on the project -- the consequence is that the project has less effect than you might think on the curve. A warning, however: if you punt the project, you will fail the course.

In some courses, the TAs and instructor have to spend a lot of time dealing with regrading appeals, time that would be better spent helping students learn the material. Absolutely come to us if we make an arithmetic error, but realize that a few points here and there are extremely unlikely to make any difference in your final grade. If you believe that we assigned too little credit for your work, you may submit your work for a regrade under the following restrictions. (1) All regrade requests must be submitted with a clear, written statement that explains why you believe the original grade was incorrect. (2) All requests for regrades must be submitted within 1 calendar week of when the graded work is returned. (3) We will regrade the entire exam, problem set, or project assignment, and if we were overly generous we will deduct points. Thus, you grade can go up or down on a regrade.

Late policy. No extensions will be given for completing the homeworks or the programming projects, except that students will be allowed 4 flexible slip days for the projects and one slip day for homeworks during the semester. A student may divide his or her slip days across projects in any way he or she wishes to extend deadlines for the projects (or a homework.) To help the TA track your slip-day status, the top of your project README file (or your homework) should include the line:

Slip days used (this project): _______ Slip days used (total): ______

Cooperation and cheating. We encourage you to discuss the problem sets and programming assignments with your colleagues. We welcome discussions of possible interpretations of questions, solution approaches, and relevant technical details. You are also welcome to use existing public libraries in your programming assignments (such as public classes for queues, trees, etc.) You may also look at operating systems code for public domain software such as Linux. Such activities qualify under approved collaboration practices and you are welcome to take advantage of them.

Note that cooperation is not the same thing as cheating. It is OK to ask someone about the concepts needed to do homework or project assignments. However, copying other people's code or solution sets is strictly prohibited. The homework, project assignments, and exams must be the work of students turning them in. Students who violate University rules on scholastic dishonesty are subject to disciplinary penalties, including the possibility of failure in the course and/or dismissal from the University. Because such dishonesty harms the individual, all students, and the integrity of the University, policies on scholastic dishonesty will be strictly enforced.

A simple proceedure to keep yourself on the right side of the line is that after a student (or the TA!) helps you with an assignment, go watch Gilligan's Island for a half hour, then go back to working on the assignment. If you can't remember what the person said after a half hour, you didn't really understand it.

Acts that exceed the bounds defined by the approved collaboration practices will be considered cheating. Such acts include:

• Copying solutions, code, or programs from someone else or giving someone else your solutions, code, or programs.
• Getting help in debugging
• Participation in a discussion group that develops a solution that everyone copies.

Midterms. There will be two midterms given jointly across Alvisi's, Dahlin's, and Elnozahy's sections at the dates and times listed below. If you have a conflict with either midterm, let the instructor know during the first week of class and we will schedule a makeup for a time before the exam is given to the rest of the class. Both exams will be closed book and will cover material from lecture, readings, homeworks, and the project. In particular, you are likely to do poorly on the exams and in the course if you sleaze out of the project by making your project partner do all the work.

Project. Perhaps the most valuable part of this class will be the programming assignments. You will construct a simulator of a portion of an OS, practice good concurrent programming techniques, and construct two major pieces of an OS. The first two projects will be done individually; the others will be done in groups of two. Forming the partnership is your responsibility. We prefer not to be involved in match making, although we will try to help the handful of you who cannot find a partner. Problems that arise during the partnership are also your responsibility, but we will try to mediate in grave situations. You may elect to work by yourself, but we strongly recommend against doing so because of the amount of work involved. You will not get an extension because you have elected to work by yourself.

We will use flexible slip dates for the project. Further details about the project will be covered in later handouts.

Problem sets. We will assign three written problem sets. The problem sets are designed to focus on the types of questions students typically have difficulty with on exams. The idea is to give you the opportunity to think more deeply about the concepts presented in the course. Unlike the project, the problem sets are to be done individually. The due dates for the problem sets will be announced during the semester. Problem sets may not be turned in late. Problem sets must be type set. Handwritten problem sets will not be graded.

Self-quiz. We will regularly post self-quizzes for you to test your knowledge of the material. The solutions will also be posed. The intent is for you to use these as self exams to assess your understanding of the course material and evaluate your performance, all without affecting your grade. Of course, the lack of an actual grade or a deadline for taking these quizzes may be an invitation for procrastination or even ignoring this process altogether. But we trust that you will find this a very useful aspect of the class and we strongly urge you to take advantage of it. To make effective use of this feature, you will find it best if you would take the quiz as soon as it is posted on the web so that you know where you stand. Delaying the quizzes with the intent of accumulating them and solving them at once before the exams is not an effective strategy.

(Approximate) Schedule

Sermons

• Sermon 1: Simplicity
• Sermon 2: Performance Tuning
• Sermon 3: Programming as Craft
• Sermon 4: Information = Property
• Sermon 5: Stay Broad
• Sermon 6: Project efficiency v. risk

Project Information

• Project Instructions
• Project 1: CPU Simulator
• Project 2: Multi-threaded programming
• Project 3: Database disk subsystem
• Project 4: Network TBA
• Background

I assume that everyone in the class has reasonably strong programming skills and that you are comfortable using the basic tools of the trade (debuggers, makefiles, etc.) Here are some references if you need to brush up on any of these basic skills.
• A Quick Introduction to C++ Anderson: There are many features in C++ that are more dangerous than they are worth. This is an excellent primer for those not familiar with C++. It is also recommended reading for experienced C++ programmers.
• GDB and GDB reference card: If you currently debug with printf's, spend a couple hours learning GDB. It's not hard, and I promise you will save time in the long (or not-so-long) run.
• make You should know how to use make!
• Version control (keeping track of old versions of software before you added the last bug) is essential for large software projects. CVS is a sophisticated for allowing concurrent editing in a multi-programmer project. RCS is simpler, but less flexible (see "man ci" to get started).