Welcome! This course is an introduction to computer systems software---low-level software abstractions with an emphasis on the connection of these abstractions to underlying computer hardware. Key abstractions include threads, dynamic memory allocation, protection, and I/O.
There are three interrelated goals for this course. The first goal is to understand how operating systems and, more generally, computers work. Students graduating with CS degrees 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.
The second goal is for you to learn the core ideas in operating systems: virtual addressing, memory protection, concurrent programming, file systems, scheduling, transactions, etc. Often, but not always, such ideas are best explained as abstractions that some software layer (usually the operating system) provides above imperfect hardware to make that hardware usable by programmers and users. The intent is for you to understand such abstractions well enough to be able to synthesize new abstractions when faced with new problems.
Many of the ideas and abstractions that we will cover are relevant not only to OS kernels but also to many large-scale systems. Thus, a third goal of this course is to enhance your ability to understand, design, use, and implement such systems.
During this course, you will have an opportunity to learn a lot of practical information about how programming languages, operating systems, and architectures interact and how to use each effectively. The written and programming assignments are designed build on and enhance the lectures. You will hear the concepts in lecture, read them in the book, analyze them in the written homework, and put them in practice in the programming assignments.
Office hours will begin on Tuesday, 9/3.
Instructor: Alison N. Norman
Office Hours and Location: Monday 11a-12:30p and Wednesday 11:30a-1p both in GDC 6.816
(If it seems no one is coming, I may return to my office, GDC 6.310. If you can't find me, try there.)
Teaching Assistant: Aming "Nick" Ni
Office Hours and Location: Tuesday 9a-11a and Friday 11a-1p both in GDC 1.302, Desk 1
Teaching Assistant: Navid Yaghmazadeh
Office Hours and Location: Thursday 2:30p-4:30p and Friday 9:30a-11:30a both in GDC 1.302, Desk 5
Undergraduate Teaching Assistant: Ben Bowley-Bryant
Office Hours and Location: Wednesday 4p-6p and Friday 3p-5p in GDC 3.302
Undergraduate Teaching Assistant: Clare Coleman
Office Hours and Location: Tuesday 11a-1p and Thursday 11a-1p in GDC 3.302
Undergraduate Teaching Assistant: Di Hunyh
Office Hours and Location: Monday 3p-5p and Tuesday 4p-6p in GDC 3.302
Lecture Meeting Time and Location:
Sections 53895, 53900, 53905: Undergraduate Teaching Center (UTC) 3.132 MW 9a-11a
Sections 53910, 53915, 53920: Liberal Arts Building (CLA) 0.102 MW 1p-3p
Turn off cell phones, laptops, and other digital devices during lecture. Failure to do so results in loss of iClicker participation points.
Discussion Section Information:
|Section Number||Meeting Time||Meeting Location||TA|
|53895||F 9a-11a||GSB 2.122||Di, Nick|
|53900||F 11a-1p||JES A215A||Ben, Clare|
|53905||F 1p-3p||JES A217A||Clare, Di|
|53910||Th 8a-10a||GDC 4.302||Nick|
|53915||Th 10a-12p||GDC 1.406||Navid|
|53920||Th 12p-2p||GDC 1.406||Navid|
Students must attend the discussion section for which they are officially registered.
This handout and all other information for the course will be available at this address.
Prerequisites: CS 429 or 429H with a grade of
at least C-.
Clickers: An iClicker is required for this course and must be
brought to every lecture as participation on iClicker questions is
part of your course grade. For this class, an iClicker is sufficient.
However, an iClicker+ or an iClicker2 will also work.
Register your iClicker at http://www.iclicker.com/registration/ by providing:
Even If you already have an iClicker and registered it to your EID in the past, you must re-register for this semester.
Discussion: The class discussion board is on Piazza. You may sign up at this link: http://piazza.com/utexas/fall2013/cs439n. (Note that the course is listed as "CS439N".)
I will post course-related announcements and information on the board. You must read the discussion board, and you should post course-related questions and responses there. I expect you to make good use of the discussion group and of TA and proctor support when you have technical or administrative questions or problems.
You are responsible for any and all information posted to Piazza by any of the course staff.
Email to you: In this course, email will be used as a means of communication with students. You are responsible for checking your CS email regularly for class work and announcements. Your CS address may be forwarded to another account (see http://apps.cs.utexas.edu/udb/update/).
Email to the Instructor or TAs: Emails to me, the TAs, and the proctors should begin with "CS439:" in the subject line, followed by a brief description of the purpose of your email. If you follow this rule we will be better able to address your questions in a timely manner.
Course Structure: Lectures will introduce systems concepts through description and examples. A key component of this course is the active participation of students. While I will lead you through the main concepts and provide you with details relevant for understanding and applying those concepts, you have to provide the "active learning" component. By active learning, I mean you must do things, think about things, ask questions---basically whatever it takes for you to be engaged. The format is informal; questions are welcome all the time.
Assignment/Lecture Schedule: A schedule of lecture topics, reading assignments, and assignment distribution and due dates is available online, via the class web page. The schedule page contains links to lecture slides and assignments. Readings are to be completed before class.
The schedule is subject to change.
Required Effort: The workload for this course is heavy. There are readings, five projects, ten homeworks, two exams, and a final.
To maximize your learning, it is essential that you read the text prior to each class meeting. The ideas in this course require thinking about and getting used to, which is possible only with multiple exposures to the material. Also, the readings can be difficult---so be patient. Finally, the concepts build on each other, so you must stay current. Please make up any missed classes on your own or with help from your colleagues.
Professionalism: Professional conduct is built upon the idea of mutual respect. Such conduct entails (but is not necessarily limited to):
Exams and Final: Exams will cover material from lecture, assignments, and assigned readings. The exams will be held in the evening on Tuesday, 10/1, and Wednesday, 11/6.
The final will be cumulative, but it will be more heavily weighted towards material that has not yet been tested. It will be on the day and time scheduled by the registrar.
iClicker Participation: iClicker participation is measured in your answers to iClicker questions, so bring your iClicker with you to lecture. In order to receive iClicker credit for a given day you MUST:
You are required to attend class, and you are responsible for knowing or learning any material presented in class. If you must miss class, you are not required to inform the instructor, but you are responsible for learning any material you missed. The instructor posts detailed notes for each class on the course web site, but classes are interactive, so the actual discussion may depart from the notes. The best way to know what actually happened in a class is to be there and participate; if you must miss a class, you should study the notes carefully and perhaps talk to your colleagues about the technical topics discussed and what points were particularly emphasized.
Use of laptops, phones, or other digital devices during lecture results in the forfeiture of iClicker participation points.
Discussion Section Attendance: Attendance at discussion section is mandatory, and you must attend the one for which you are registered.
Homeworks: There will be approximately ten written homework assignments during the semester.
Homework problems assigned on the course website will be turned in using the turnin program before any discussion sections begin.
The first half of the discussion sections will generally focus on completing an additional homework problem and, afterward, discussing the homework. It is essential that you work on the problem sets before the discussion section in which they will be discussed both to maximize the benefit you get from the discussion and so that you can contribute to the discussion.
We will typically grade homeworks on a "OK/Not-OK" basis, where "OK" means that you made a credible effort to solve the problems (even if you make a mistake.) We reserve the right to grade for correctness as well.
Homeworks must be turned on time without exception, but the lowest two homework scores will be dropped. Failure to attend discussion section and complete the final homework question results in a loss of credit for the entire homework.
Projects: There will be approximately five programming projects during the semester. The due date for each project will be clearly stated. Plan to start early since debugging operating system code can take arbitrarily large amounts of time. Additionally, respect Murphy's rule and plan for your bus to run late, your personal computer to crash the afternoon of the due date, etc.
For each group project, your group members will evaluate your contribution. If your median rating is an unsatisfactory or less for 3 or more projects, your final course grade will be reduced by a letter grade.
All projects must be submitted using the turnin program. We will not accept assignments e-mailed to us. All projects are due just before midnight (11:59pm) on their due date. Projects are dated by the turnin system.
Projects must be submitted in the correct format and named correctly. Projects that do not compile or are named incorrectly will receive a 0. We will release a script to help you test that your code will compile correctly. Use it.
Late Policy: You will have 4 slip days in 1 day units (that is, 1 minute to 24 hours late = 1 slip day, etc.) to use throughout the semester to extend project deadlines. However, you may only use two slip days on any particular project. Other than that, you may divide your slip days across the projects in any way you wish, subject to the 4 day total and the 2 day per project maximum. Slip days are to account for life circumstances and emergencies. Do not use your slip days frivolously. If you use all your slip days and then cannot turn in your project on time for any reason then you will receive a 0 for that project.
Grading: Grades are essential to insuring that your degree has the value that it deserves. As a result, we have a grading system that has two essential properties:
These class components are used to determine your final average in the following manner:
|iClicker Participation||6%||Determined by responses to questions with the iClicker. If you respond to a question during at least 80% of the classes, you will earn the full 6%.|
|Homeworks||8%||Approximately ten written homework assignments will be given during the semester. These assignments are designed to enhance understanding of the concepts and help prepare for the exams. The lowest two homework scores will be dropped.|
|Projects||32%||Approximately five large-scale programming projects.|
|Exams (2 total)||16% each||Exam 1 will cover the first third of the course, Exam 2 will cover the second third. Both are closed-book.|
|Final||22%||The final will be cumulative but will be more heavily weight towards the last third of the course. Closed-book.|
The course will be graded on a curve, with the score-to-letter-grade mapping determined by the instructor based on factors such as the difficulty of an assignment, the types of errors people are making, etc. During the semester, I will give rough estimates of where grade cut-offs lie, but these will be deliberately somewhat vague; if knowing where a cut-off is within a few points will affect how you study, you're worrying too much about grades and not enough about the material (Plus, it's a really bad idea to gauge your effort by what you think you need to make to get a particular letter grade). I want everyone in the class to do well, and if everyone masters the material and gets good marks, I will happily abandon the curve and give "extra" A's and B's. In particular, I guarantee that anyone who gets a grade of 90% or more of the total points will get an A, anyone with 80% or more will get at least a B, and anyone with 70% or more of the points will get at least a C.
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 exam 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 worry is misplaced. First, I will set grade cut-offs for each assignment to correspond to the quality of the work and depth of understanding reflected by each range of scores and not by the number of students that make each range of scores. Second, note that the impact of any individual score on the overall class distribution is trivial -- for example someone making a 10% better grade on a exam raises the class semester average by .1%.
Also, for these types of projects 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 not something to worry about. The projects are hard enough without looking over your shoulder at other students. By and large, most students do quite well on the projects---the consequence is that the projects have less effect than you might think on the curve. A warning, however: if you punt the projects, you will fail the course.
Your grades are recorded in the gradebook on Canvas.
If you have questions or concerns about your grade, contact your TA during office hours or by email.
Grade Changes: If you believe your work was graded incorrectly, you may submit a written or email complaint to the grader. The complaint must be submitted within one week of the date on which we first attempted to return the graded work to you. Your complaint must contain supporting evidence and arguments which explain why your work was graded incorrectly. (For example, it is not sufficient to submit a note that says "regrade question 3".) Grade change requests that do not meet these requirements will not be considered. Note that assigned grades are not the starting point of a negotiation. This isn't a weekend bazaar---unless we have made a mistake in grading your work (i.e., you have a correct answer that was marked wrong, or your score was added incorrectly), your grade is final.
Note that none of the following grade discussions is appropriate:
Pair and Group Programming: On most or all of the projects (as specified in the project description) you must work with at least one other person. You must follow the pair programming guidelines below and on the course web page. All students will receive the same grade for the project. Unless group or pair programming is specifically allowed, all assignments must be done alone---including all homeworks.
We use pair programming because it is a more effective and time efficient way to learn the material. Researchers have shown that students perform better in the class in which they use pair programming than without, and also they perform better in subsequent classes with or without it. These results indicate that you learn more and better with pair programming. Please read:
You must follow the pair programming guidelines: the pair must sit, design, and program together at least 80% of the time, and split keyboard time evenly. Each student can work independently for at most 10% of the effort/time. The person at the keyboard is the driver, and the person sitting next to him/her is the navigator. We recommend you alternate driving and navigating every 30 minutes.
For some parts of the course, you will be allowed to change partners between assignments. However, once you begin an assignment with a partner (or a group), you cannot change partners or groups for that assignment. If you must stop working with your partner, please request permission from the instructor and await further instruction.
You are encouraged to study for exams, discuss the homeworks and projects, and discuss debugging techniques with your colleagues. You are 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. You may not look at any course project material relating to any project similar to this course's class projects. For example, you may not look at the work done by a student in past years' courses, and you may not look at similar course projects at other universities. If you are unsure about whether a particular source of external information is permitted, contact the instructor before looking at it.
Note that cooperation is not the same thing as cheating. The project, homeworks, and exams must be the work of the student turning them in. Materials from the web should only be used for educational purposes. For example, you can read about threads and look at examples of thread code, but you must not copy any code from the web or be looking at any of this code from the web when writing anything you turn in. If you discuss an assignment with another student or look at examples from the web, you should employ the following technique: after a discussion with another student or looking at example code you should do something that has nothing to do with computer science or programming for at least half an hour before resuming programming.
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. The penalty for cheating on an exam, quiz, or assignment in this course is an F in the course and a referral to the Dean of Students office.
It is generally okay to verbally discuss the concepts needed to do projects or homeworks. Three guidelines will help you keep on the right side of the line.
Note that these guidelines are necessarily generalizations and cannot account for all circumstances. Intellectual dishonesty can end your career, and it is your responsibility to stay on the right side of the line.
Examples of cheating include: looking at someone else's program, writing your program while talking to someone else about it, talking another student through the solution code, allowing others to look at your solution code, and looking on the internet for code to solve your programming assignments. If you have any doubts about what is allowed, ask the instructor.
Plagiarism detection software will be used on various assignments to find students who have copied code from one another. Any program that you submit must be yours, and yours alone.
If you are participating in a pair or group programming assignment and your partner cheats, you are also culpable. Either you were following the rules of pair programming and you knew your partner(s) was cheating, or you were not following the rules of pair programming and you turned in work as yours that was not.
Religious Holy Days: A student who is absent from an examination or cannot meet an assignment deadline due to the observance of a religious holy day may take the exam on an alternate day or submit the assignment up to 24 hours late without penalty, if proper notice of the planned absence has been given. Notice must be given at least 14 days prior to the classes which will be missed. For religious holy days that fall within the first 2 weeks of the semester, notice should be given on the first day of the semester. Notice must be personally delivered to the instructor and signed and dated by the instructor, or sent certified mail. Email notification will be accepted if received, but a student submitting email notification must receive email confirmation from the instructor.
Students with Disabilities: The University of Texas at Austin provides upon request appropriate academic accommodations for qualified students with disabilities. For more information, contact the Division of Diversity and Community Engagement, Services for Students with Disabilities at 471-6259, 471-4641 TTY. Students requesting accommodations for disabilities must notify the instructor by the 12th class day.
This syllabus is a plan of action for the semester. It is NOT a contract and is subject to change. As the instructor, I reserve the right to make additions, deletions and modifications to the syllabus and the course requirements with reasonable notification to the students enrolled in the course. You are responsible for any changes announced in class or on the course website.
In the preparation of this course, I used materials from Mary Eberlein, Mike Scott, Kathryn McKinley, Shyamal Mitra, Calvin Lin, Charlie Garrod, Jennifer Brown, Al Mok, Mike Dahlin, Emmett Witchel, Lorenzo Alvisi, Maria Jump, Michael Walfish, Jerry Breecher, and Andy Wang.
Copyright Notice: These lecture notes, homeworks, and projects are part of a second course on computer 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.