Return to the 15-412 Home Page

15-412: Operating Systems

Course Syllabus

Gregory Kesden

Table of Contents

Class Meetings

Course Description


Teaching Assistants 
Tentative Schedule
Policy on Collaboration
Policy on Late Work

Class Meetings

Monday, Wednesday, and Friday, 10:30-12:20, Wean Hall 7500

Course Description

Operating systems monitor the execution of user programs and the allocation of various system resources such as memory space and peripheral devices. The course introduces the basic concepts of multiprogramming, timesharing and asynchronous processes. These concepts lead to interesting problems of synchronization, scheduling, memory management, information sharing and protection. Emphasis of the course is on the design aspects of operating systems. (Undergraduate Catalog). 


The prerequisite for this course is the 15-213 or 18-347, or equivalent (Undergraduate Catalog). In particular, you must be familiar with data structures and basic computer architecture concepts. You must also be proficient in C programming on UNIX systems.


The textbook for the course is Operating System Concepts, by Silberschatz and Galvin, sixth edition, published by Wiley, 2002. It is available in CMU's bookstore. We will cover some topics in more depth than in the book, and will also cover some in a slightly different order.

Additional reading assignments may also be handed out in class during the semester.


Gregory Kesden

·        Email:,

·        URL:

·        Office: WeH 8020

·        Office Phone: 268-1590

·        Home Phone: 687-6198

·        Office Hours: M-Th 2:30-4:00

Please note:

Office hours are times that I do my best to reserve exclusively for meeting with students, but I am often available at times other than office hours. During a typical day I might be available earlier, upon returning from lunch, and also for some amount of time later in the evening, upon returning after dinner – I don’t promise to be available outside of office hours, but I do try. You are welcome to stop in any time that my door is open. If you are having difficulty meeting with me, please feel free to make an appointment.

Some students have found it useful to finger me at my UNIX workstation,, or the departmental cycle server If I have a reasonably short idle time on either machine and I’m logged in locally or from my Windows box, chances are that I’m in my office.

Please note that my home phone number is published is this syllabus, as well as in many other places. If something comes up that is time sensitive and I am otherwise unavailable, you are welcome to try me at home.

I am generally not available via zephyr.

Teaching Assistants

Attila Bergou

Mike Ferdman

Ashley Gross

John Ketchpaw

Kevin Milans




Homework assignments are individual assignments designed to reinforce class material through design, analysis, restatement, or simple practice. Although each student should do his/her own homework, students are certainly encouraged to discuss the course material related to the homework to develop a better understanding.



The projects are designed for two person teams. You should try to pick a partner at the beginning of the semester and stick with him/her throughout the semester, but changes are allowed. Only if you cannot find a partner and if we are unable to find a partner for you, will you be permitted to work by yourself.  Both partners should work cooperatively on the design, implementation, and testing of their solutions. Please understand that every semester some people work by themselves – we generally don’t view this as a reason for relaxed deadlines or grading.


Projects will be graded based on the correctness and quality of the design, implementation, and function of the solution, as well as the ability of each partner to explain the solution to course staff. The quality of the design and implementation are typically measured subjectively by course staff; the function of the solution is typically measured objectively using a series of scripted tests. In some cases response time and other performance characteristics will also be assessed – if this is the case, it will discusses as part of the project description.


After your submit your project, a staff member will carefully study your solution and test it for correctness. After this is done, both members of your group will meet with the staffer to discuss your solution. Although this meeting is an opportunity to make sure that both group members are “on the same page,” it is also a great learning opportunity for you. The staffer will discuss your solution with you and get a better sense of why you did what you did. This meeting is also an excellent opportunity for you to ask questions about the project. If there isn’t enough time during the initial meeting for you to ask all of your question, please schedule another meeting. You are strongly encouraged to bring questions with you to the review, or to mail them in advance to the staffer. We want to leverage the project reviews to make them as much of a learning opportunity for you as possible.


After we have reviewed each project, tested it for correctness, examined the code, and discussed it with the authors, we will meet and discuss our findings with each other. At this time, we will determine each project’s grade. This process allows for each process to be carefully reviewed and discussed with the authors and the other graders, it provides for uniform grades, and an excellent learning opportunity for you – but it does take time. Please understand that this process takes, at a minimum, two weeks from submission to final grade.


Since both partners’ grades could conceivably suffer if only one member of the group doesn’t express an understanding of the solution, it is worthwhile to work together to ensure that both members of your group are “on the same page.” If problem do develop during the course of a project, please speak to a staff member as early as possible – we will do everything we can to help you with the situation. Talking to us about this type of situation also helps us to understand the dynamics of your group – this can often help us to assign grades more fairly. In general, both members of the group will get the same score for the project – but special circumstances may warrant special treatment.



The exams may cover any material covered in the course. This includes the material from the lectures, from the assigned sections of the textbook, from the additional reading assignments handed out, from the programming projects, or from the homework.

The material covered by exams is not intended to be a surprise. The type of questions asked on each exam will vary with the material and the configuration of the particular exam.  Some typical question categories might include the following:

o       Use a simple mathematical model of a system component to estimate its behavior, performance, or resource requirements

o       Design a modification to a familiar system component to incorporate a new or modified feature

o       Analyze the design features of a system component based on the cost and benefit of each important design decision.

o       Apply a technique or tool studied in class to a particular problem.

o       Perform a cost-benefit analysis of two or more tools, techniques, or implementations for solving a particular problem.

o       Describe an approach, algorithm, or data structures used by operating systems to solve a particular problem

o       Define or describe or draw a particular “term”, or differentiate between two or more such terms.



Your final grade for the course will be computed based on the following weights for the individual assignments:



First programming project 


Second programming project 


Third programming project 


Fourth programming project 


Midterm exam 


Final exam 


Each homework (10% total) 


In addition, your weighted project average and weighted exam average must each be a passing grade in order to pass the course.


Since this is an 18-unit course, there is a substantial amount of work involved. Our best advice to you is to start each assignment early; don't wait till the last few days to try to do all the work. In particular, you will need to start on the programming projects early in order to make good use of your time during the assignment. These projects can be enriching if you stay on top of them; they can be impossible if you don't.


It is a good idea to plan to finish each project 15%-20% early. If you do this, you will have plenty of time to clean up and improve your solution at the end – and you will have slack in your schedule in the event of the inevitable.

Course Communication

We will use the Andrew bulletin board academic.cs.15-412.announce to post announcements related to the course. You should check this bboard regularly for schedule changes, clarifications and corrections to assignments, and other course-related announcements. Urgent changes may be broadcast using e-mail, but we try to be considerate and avoid pushing mail into your box.

There is also another bulletin board for the course, academic.cs.15-412, where anyone can post messages pertinent to the course. Although these will not be ``official'' messages, you may find the discussions there useful. We encourage you to use this bboard as a class resource. The TAs and instructors will not necessarily be monitoring this bboard.

If you would like to ask us a question about the course, we encourage you to e-mail the distribution list. This list is monitored by the course staff on a regular basis. We archive questions and answers of a non-personal nature (sometimes edited) on the course website – you might find this archive useful. If you would like us to respond to a bboard bost, please address your message to both the staff-412@cs list and the bboard. You are, of course, welcome to e-mail an individual staffer or to drop by one of our offices – but e-mail is often more convenient.

The course Web site,, is home to an outstanding collection of resources. The Web site houses copies of many handouts, such as this syllabus, as well as the staff-412@cs Q&A archive,  the course calendar, lecture notes, and many other resources.

Tentative Schedule

A tentative schedule for all assignments in the course will be available on the course Web page. Please check it frequently for updates.

The midterm exam is currently planned for Wednesday, October 17th, 2001. It will be an in-class, closed-book exam, covering all material up to that point in the course.

The final exam will be a 3-hour, closed-book exam, covering all material for the entire semester, but with some emphasis on material from the second half of the course. The date and time of the final exam will be scheduled by the University.

Policy on Collaboration

For homework and programming assignments, students are encouraged to talk to each other, to the course staff, or to anyone else about the assignments. This assistance, though, is limited to the discussion of the problem and perhaps sketching of general approaches to a solution. Each student must develop his or her own solutions to the homework. Each group must develop their own solution to the projects. Consulting another student's or group's solution is prohibited, and submitted solutions may not be copied from any source. Violations of this policy may be treated as academic dishonesty pursuant to the University regulations.


If you question the legality of any type of collaboration or consultation, please ask. If you are in a real bind, do what feels right and discuss the issue with a staffer as soon as is possible. If you discuss the issue with us before you turn in your solution or document it as part of your solution, it will not be considered to be academic dishonesty or any other crime of moral turpitude (of course, it might not qualify for full credit, either).

Policy on Late Work

Each student may grant himself or herself an extension on any homework assignment or project deadline/checkpoint – but only four (4) days worth of extensions may be granted to any student during the course of the semester under this policy. Possible configurations include turning in each project one day late, turning in each homework assignment one day late, turning in two projects each two days late, &c.


The projects do pose a couple of special issues. First, each group member must have a sufficient number of “extension days” to support the entire exception.  Let’s assume that one member of a group, Jane, has all four days and the other member of the group, John, has only two days remaining. If the project is more than two days late, John cannot receive credit. Given this, the project should be submitted within two days after the due date – the group is not permitted to divide and produce separate solutions and it wouldn’t be fair to John for him not to receive credit for his work.


The second issue is that of checkpoints. If a group uses an extension day for a checkpoint, it automatically will push each subsequent checkpoint and the deadline back..


Although homework assignments are candidates for extensions, you should consider the costs and benefits of this use very carefully. Homework assignments don’t count nearly as much as projects, and using extensions for homework may make you unpopular with your project partner. But, if something insurmountable comes up, it might be a good use. This is for you to decide.


Please also understand that the use of extensions may, perhaps severely, delay the grading of your assignment. This isn’t intended as a punishment, it is just the natural consequence of the need to have all of the staff assembled to fairly assign grades. We’ll do our best to be timely – but once extensions are injected into the system, this can become difficult.


I encourage you to reserve extensions for the inevitable – minor illnesses, deaths in the family, conferences, University trips, bad karma, &c. But you are free to use them for any reason that you’d like – but remember you only have five days worth of extensions! My sense is that an extension for “no reason” might be most valuable for project #4, due at the end of the semester during “project season” – you might want to “save up.”


To grant yourself an extension, please send an e-mail to the staff-412@cs mailing list identifying yourself (and your group, if applicable), the reason for the extension, and the number of days of an extension that you are granting yourself. Up to four days of extensions will be granted, regardless of the reasons, but we do require the reasons so that we understand the factors influencing each person/group. This e-mail must be sent on or before the assignment due date/checkpoint.


This system grants you a great deal of flexibility – and also responsibility. Feel free to consult with us about your situation – but ultimately the decisions are yours. Extensions beyond the four days available under this policy will only be granted for extremely unusual, extremely unforeseeable, and/or extremely incapacitating circumstances. It is likely that we would require significant evidence of the circumstance and would consult with administrators and/or academic advisors before granting any further extensions. Further extensions, if granted, may involve a substantial late penalty.