Remember to check this regularly
- Have a good break!
ProfessorFabián E. Bustamante
Technological Institute, L465
+1 847 491-2745
Office Hours: By appointment
Ford Design Building, 2-217
+1 847 467-3250
Office Hours: Tuesdays and Thursdays 3:00-4:00PM.
Final ExamDec. 3 (in class).
Catalogue Description: Fundamental overview of operating systems. Operating systems structures, processes, process synchronization, deadlocks, CPU scheduling, and memory management.
Detailed Description: Operating systems control all of a computer's resources and present users with the equivalent of virtual machines that are easier to program than their underlying hardware. This course provides an overview of fundamental operating system principles, complemented with discussions of concrete modern systems to help you understand how these principles are applied in real OSs. Topics covered include an overview of the components of an operating system, mutual exclusion and synchronization, implementation of processes, scheduling algorithms, memory management and file systems.
Although the main learning objective of the course is to understand the requirements, design and implementation of modern operating systems, at a higher level the course aims to provide you with a good grasp of basic abstractions employed in system-level software (such as processes, threads, virtual memory, caching, etc.), while uncovering the ``magic'' that happens inside the box.
The course has a strong project component intended to provide essential experience in designing and implementing complex systems and working as part of a team. In designing the projects and estimating their required effort/hours, I am assuming you are (1) familiar with basic computer organization and data structures and (2) capable of programming in C in UNIX (or UNIX-like) systems (experience with pointers, explicit dynamic memory allocation, multi-file projects, etc.).
Location and Time
Tuesdays and Thursdays 4:00-5:20PM.
- TA Sessions:
In compliance with Section 504 of the 1973 Rehabilitation Act and the Americans with Disabilities Act, Northwestern University is committed to providing equal access to all programming. Students with disabilities seeking accommodations are encouraged to contact the office of Services for Students with Disabilities (SSD) at +1 847 467-5530 or email@example.com. SSD is located in the basement of Scott Hall. Additionally, I am available to discuss disability-related needs during office hours or by appointment.
- EECS-311 Data structures and data management.
Introduction to Computer Systems or
EECS-205 Fundamental of Computer Systems Software and
EECS-231 Advanced Programming for Computer Engineers.
- Familiarity with basic computer architecture concepts and proficiency in C programming in UNIX systems.
There are a number of communication channels set up for this class:
- We will use the course web site to post homework assignments, projects, course-related announcements, etc. You should check this regularly.
- There will be a newsgroup (cs.343 at news.cs.northwestern.edu). This particular channel is intended to foster communication among you, the students. You'll find that someone else in the class will have thought of the same problem that you have and will perhaps have some valuable insight that will prove helpful. The staff will be monitoring the discussion threads and will step in with guidance when appropriate.
- Finally, there is an email alias (cs-343-ta@cs) for the TA that you should use for questions that would be inappropriate to post on the newsgroup (source code being a good example).When using email to contact the staff, please start your subject line with "eecs343: helpful-comment" to ensure a prompt response.
Textbook and Other Readings
- Operating System Concepts, 8th Ed., A. Silberschatz, P. Galvin and G. Gagne. John Wiley & Sons, 2009. (Textbook).
- Supplemental Reading. A set of papers I will make available providing a deeper historical perspective of operating systems, in-depth treatment of some of the topics I can only briefly cover in class, and some useful practical advice in designing and implementing complex systems. You will not be responsible for this; it is only intended for those specially interested in the given topic.
- Advanced Programming in the Unix Environment, R. Stevens, Addison-Wesley, 1992. A fantastic reference book for anyone writing programs that run under Unix (Highly recommended). There is also a nicely updated second edition out there.
- The C Programming Language, 2nd Ed., B. W. Kernighan and D. M. Ritchie, Prentice Hall, 1988. ``The'' reference book (Recommended).
- Chapter 12 Kernel Memory Allocation, In UNIX Internals: The new frontier, Uresh Vahalia, 1996. A nice presentation of KMA, algorithms and their evaluation.
- The Practice of Programming, Brian W. Kernighan and Rob Pike. Addison-Wesley, 1999. There is more to writing a program than getting the syntax right, fixing the bugs you have noticed, and making it run fast enough. Programs are read not only by computers but also by programmers. A well-written program is easier to understand, grade, and modify than a poorly-written one. This book is packed with great practical advice on style, design, interfaces, testing and debugging, maintenance, ...; all issues that programmers must deal with in the real world (Recommended).
When reading papers it is normally useful to write down a summary of about a page. Your summary should include at least:
- Paper title and its author(s).
- Brief one-line summary.
- A paragraph of the most important ideas: perhaps a combination of their motivations, observations, interesting parts of the design, or clever parts of their implementation.
- A paragraph of the largest flaws; maybe an experiment was poorly designed or the main idea had a narrow scope or applicability. Being able to assess weaknesses as well as strengths is an important skill for this course and beyond.
- A last paragraph where you state the relevance of the ideas today, potential future research suggested by the article, etc.
You may find the following brochure useful: Efficient reading of papers in Science and Technology by Michael J. Hanson, 1990, revised 2000 Dylan McNamee.
The course is organized as a series of lectures, TA sessions, reading, homework, projects and exams:
- Lectures - A set of lectures through which I present the core of the material.
- TA Sessions - Discussion sessions held by the TAs to answer questions about the lecture, readings, homework assignments, and projects.
- Readings - Textbook reading in preparation for (not substitution of) the lecture and additional reading for those interested in delving further into some topics.
- Homework - Four homework assignments with questions from (or similar to those in) your textbook, aimed at reinforcing the material covered in the reading and the lectures. A last homework assigment on the reading material for our last lecture.
- Projects - Four programming projects to give you a better understanding of the subject matter and some experience with system level programming including thread-level programming.
- Exams - Two exams, a midterm and a final exam. These exams cover the material presented in the lecture, homework assignments and projects. You'll be able to bring one page of notes to assist you during the exam.
There will be two kinds of homework assignments given throughout the class: reading assignments and textbook-style questions. You should have finished the assigned reading before coming to lecture. In addition, there will be a set of written homework assignments that must be done alone and turned in by midnight on the due date (see course policies below).
|1: Introduction to Operating Systems||09/22||10/02||-|
|2: Processes and Threads||10/06||10/16||-|
|3: Memory Management and Virtual Memory||10/30||11/11||-|
|4: File Systems and I/O||11/14||11/24||-|
|5: Research in Operating Systems||12/01||12/01(in-class question)||--|
To submit your homework solutions (ASCII text only!) use the following page: SUBMISSIONS.
As you can deduce from the allocation of weights for grading, programming projects make up a major portion of this class. There will be three (3) projects. All projects are to be done by teams of two (2) people. Both partners should work cooperatively on the design, implementation, and testing of their solution.
For advanced undergraduates and graduate students - this year you will also have the chance to propose your own project for the quarter. If you are interested in this, please contact me the first day of class.
The following table of deadlines should serve you as a guideline for planning your quarter. Note that the first project has two deadlines, the first one just a week after the project is assigned. After that, you are given about two weeks per project. This should be plenty of time if managed carefully. Keep in mind that projects cannot be handed in more than three days late (check the course late policy for details).
You can get a copy of the handout and skeleton for any of your projects here. The skeleton for any project would be available in the format blah.tar.gz. You should save (transfer) this file to your Unix box and run % gunzip blah.tar.gz and % tar xvf blah.tar, in that order. This will create a skeleton directory that will include the source code and makefile for the skeleton as well as the associated regression testing framework.
Here is a list of potentially useful links:
- Working with unix/linux.
- Peter Dinda's Unix Systems Programming In A Nutshell.
- Emacs/XEmacs -- while you can use whatever editor you like best, XEmacs has some useful libraries for C programming.
- C power:
- Writing Makefiles -- Peter Dinda's Make Introduction.
- gdb to the rescue -- a nice short tutorial.
- Pair programming and how to do it.
- Keeping track of changes with version control system software -- a short introduction to CVS.
Info on the Teaching Lab.
To submit your projects use the following page: SUBMISSIONS.
|1: A micro which command||09/28||10/09||--||--|
|2: A tiny shell||10/12||10/23||--||--|
|3: Kernel memory allocation||10/26||11/10||--||KMA doc|
|4: Simple file system||11/11||11/23||--||--|
There will be a midterm and a final exam. Exams will be in-class, closed-book (except for one page of notes you are allowed to bring in), and will cover materials from lecture, required readings and projects. The final exam will not be cumulative.
I use a criterion-referenced method to assign your grade; in other words, your grade will be based on how well you do relative to predetermined performance levels, instead of in comparison with the rest of the class. Thus, if a test has 100 possible points, anyone with a score of 90 or greater will get an A, those with scores of 80 or greater will get a B, those with scores of 70 or greater will get a C, and so on. Notice that this means that if everyone works hard and gets >90, everyone gets an A.
Total scores (between 0 and 100) will be determined, roughly, as follows:
- Homework 20%
- Projects 40%
- Exams (20% each) 40%
A note about class participation: while not explicitly included as an item in the previous list, your participation in class will be taken into consideration throughout the quarter and when granting partial and final scores/grades.
To check your grades you can use this form.
Course Outline and Approximate Dates
Because one has to be an optimist to begin an ambitious project, it is not surprising that underestimation of completion time is the norm.
-- Fernando J. Corbató, ``On Building Systems that Will Fail'', 1990 Turing Award Lecture.
Here's a link to the online calendar for the course, including lectures, assignments, exams, etc.
|09/24||Architectural Support for Operating Systems||2||09/29||Operating System Concepts and Structure||2|
|10/01||Processes||3 (3.6 excluded)|
|10/15||Semaphores and Monitors||6||10/20||Deadlocks||7||10/22||Memory Management||8|
|11/12||I/O||13 (13.6 excluded)|
|11/17||Secondary Storage||12 (12.8-9 excluded)|
|12/24||Protection & Security||14 & 15|
|12/01||Research in Operating Systems/Review for final||Topic will be posted in Lectures|
Unless otherwise indicated, homework assignments and projects are due by midnight on their due date. If you hand in an assignment late, we will take off 10% for each day (or portion thereof) it is late. Assignments that are three or more days late receive no credit.
Cheating vs. Collaboration:
Collaboration is a really good thing and we encourage it. On the other hand, cheating is considered a very serious offense. When in doubt, remember that it's OK to meet with colleagues, study for exams together, and discuss assignments with them. However, what you turn in must be your own (or for group projects, your group's own) work. Copying code, solution sets, etc. from other people or any other sources is strictly prohibited.