Materials

• Course Web page: http://www.cs.utexas.edu/users/witchel/372/
• Text (recommended): Andrew Tanenbaum, Modern Operating Systems (3rd Edition) ISBN-13: 978-0136006633
• Other Useful Books
  • Silberschatz, Galvin, Gagne, Operating System Concepts with Java , eighth edition. ISBN-13: 978-0470128725
  • Tanenbaum, Operating Systems: Design and Implementation
  • Assorted Java, C++, and Unix references

This course examines basic issues in operating system design and implementation. The operating system provides a well-known, convenient, and efficient interface between user programs and the bare hardware of the computer on which they run. This interface allows the OS to contain the low-level code needed to control a particular piece of hardware (e.g., a network card), while user programs contain simpler, more abstract code that is correct for a variety of hardware (e.g., different vendor's network cards, and different generations of network cards like 10Mbps and 100Mbps).  The OS protects the hardware because only OS code directly accesses it.  In this way, if the OS is correct, user programs can be incorrect, but the machine will still function.  If user programs had direct access to hardware, they would have to be correct to insure the correct functioning of the machine.  The OS multiplexes machine resources safely.  It allows multiple user programs (possibly run by multiple users) to access common resources like the network, local disc, local memory, and the CPU.  It tries to prevent user programs from interfering with each other's execution.

Operating systems have several properties which make them unique pieces of software: they are among the largest programs that exist (Windows Vista is over 50 million lines of code), they must manage concurrent execution of multiple threads of control, they must deal with the often hostile programming environment provided by raw hardware (e.g., undocumented behavior, workarounds for incorrect hardware, and timing dependent behavior), they must control their use of  machine resources (primarily CPU and memory) more carefully than most software, and they must fail less frequently than most software.  These requirements make the creation and maintenance of operating systems challenging and fulfilling.  Operating systems attract programmers who like to program.

The course will start with a brief historical perspective of the evolution of operating systems over the last fifty years, and then cover the major components of most operating systems. This discussion will cover the tradeoffs that can be made between performance and functionality during the design and implementation of an operating system. Particular emphasis will be given to these major OS subsystems: process management (processes, threads, CPU scheduling, synchronization, and deadlock), memory management (segmentation, paging, swapping), file systems, security and networking/distributed systems.

Communication

• Blackboard discussion boards.  We will use the blackboard discussion boards for all lab questions, and also any technical questions you have.  Please use them for everything but personal issues.  You must read the news group, and you should post course related technical questions and responses to this newsgroup. I expect students to make heavy use of the discussion boards and of TA support when they have technical or administrative questions or problems.
• Email to the Instructor. The subject of any email to me should begin with "372:" I receive an enormous amount of email, and if you follow this rule I will be better able to address your personal questions in a timely manner.
• Checking your grades - use UTdirect's eGradebook

Requirements and Grading

• 10-15% - Written homework, attendance, in-class quizzes and class participation
  
• 35-45% - Programming Projects
• 35-45% - 3 Exams
  • Exam 1: first 1/3 of course
  • Exam 2: second 1/3 of course
  • Exam 3: 66% on final 1/3 of course and 33% over first 2/3s of course
    

Late Policies

All homeworks are due at the beginning of class. You must turn in written homework on time without exception, because the solutions will be presented when the homework is turned in to give you quick feedback.   Please do not be late to class, especially when homework is due.

All labs are due just before midnight (11:59pm), and they are due on days we don't have class e.g.,  Friday.  Labs are dated by the turnin program.

You will have 5 slip days for your programming labs. You may divide your slip days across the 4 projects in any way you wish to extend deadlines for the projects. To help the TA track your slip-day status, the top of your project README file should include the line:

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

Cooperation and Cheating

Feel free to discuss homework and labs with other members of the class, myself, or the TA. However, do not look at or copy another students solution to a homework or lab. I am not concerned with how you come to understand the problem and how to solve it, but once you have the background necessary to solve it, you must provide your own solution. Exchanging homework or lab solutions is cheating and will be reported to the University. At the minimum, you will fail the course.  If you are ever in doubt, PUT ATTRIBUTION IN YOUR SOURCE CODE.  If you ended up reproducing a 3 line function exactly, make a note of it in your code.

The Student Code of Conduct includes your rights and responsibilities as a student.

Acknowledgments

I used course materials from Kathryn McKinley, Ron Rockhold, Tom Anderson, John Carter, Mike Dahlin, Jim Kurose, Hank Levy, Harrick Vin,  Thomas Narten, and Emery Berger  to prepare some of the course materials. Thanks!

Copyright Notice: These lecture notes, homeworks, and lab assignments are part of a first course on operating systems. You must ask me permission to use these materials.

I do not grant to you the right to publish these materials for profit in any form.

Emmett Witchel, The University of Texas at Austin