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 to 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 Monday, 1/23.
Instructor: Alison N. Norman
Office Hours and Location: Monday 1:00p-2:30p and Wednesday 3:00p-4:30p all in GDC 6.310
Guns are not permitted in GDC 6.310
Teaching Assistant: Yi-Hsuan Hsieh
Office Hours and Location: Friday 9:30a-11:30a in GDC 3rd Floor Atrium
Undergraduate Teaching Assistant: Ben Rodgers
Office Hours and Location: Monday 5:15p-7:15p in GDC 3rd Floor Atrium
Undergraduate Teaching Assistant: Chris Brackett
Office Hours and Location: Tuessday 11a-1p in GDC 3rd Floor Atrium
Undergraduate Teaching Assistant: Jasper Wu
Office Hours and Location: Thursday 2p-4p in GDC 3rd Floor Atrium
Undergraduate Teaching Assistant: Jialin Li
Office Hours and Location: Tuesday 4p-6p in GDC 3rd Floor Atrium
Undergraduate Teaching Assistant: Nick Kantor
Office Hours and Location: Thursday 12p-2p in GDC 3rd Floor Atrium
Undergraduate Teaching Assistant: Pablo Velasco
Office Hours and Location: Tuesday 4p-6p in GDC 3rd Floor Atrium
Undergraduate Teaching Assistant: Veronica Gunn
Office Hours and Location: Thursday 3:30p-5:30p in GDC 3rd Floor Atrium
Undergraduate Teaching Assistant: Zach Casares
Office Hours and Location: Tuesday 1:30p-3:30p in GDC 3rd Floor Atrium
Lecture Meeting Time and Location:
Sections 52075, 52080, 52085: Undergraduate Teaching Center (UTC) 3.122 MW 9a-11a
Sections 52095, 52100, 52105: Undergraduate Teaching Center (UTC) 4.110 MW 11a-1p
Students must attend the lecture for which they are officially registered.
Turn off cell phones, laptops, and other digital devices during lecture and
place them out of sight. Failure to do so results in loss of iClicker
Discussion Section Information:
Dicussion section attendance is required. Please see the Evaluation section for more information.
|Section Number||Meeting Time||Meeting Location||TA|
|52075 (9a lecture)||F 9a-11a||WRW 113||Chris, Nick|
|52080 (9a lecture)||F 11a-1p||WEL 2.256||Pablo, Zach|
|52085 (9a lecture)||F 1p-3p||RLM 7.124||Nick, Yi-Hsuan|
|52095 (11a lecture)||F 9a-11a||CBA 4.332||Ben, Veronica, Jasper|
|52100 (11a lecture)||F 11a-1p||CBA 4.348||Jialin, Veronica|
|52105 (11a lecture)||F 1p-3p||CBA 4.330||Zach, Jialin|
Students must attend the discussion section for which they are officially registered to receive credit for discussion section.
The website is a very important piece of this course and you should familiarize yourself with its content. This handout and all other information for the course will be available on the site.
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://www1.iclicker.com/register-clicker/ 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.
If you do not know the serial number for your iClicker but have registered it previously, you can use the Remote ID Lookup Tool from iClicker. If you have not registered it previously, take your iClicker to the ITS office in FAC to retrieve the ID. (Be sure to write it down!)
Discussion: The class discussion board is on Piazza. You may sign up at this link: http://piazza.com/utexas/spring2017/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 at least once per day, and you should post course-related questions and responses there. I expect you to make good use of the discussion group and of TA support when you have technical or administrative questions or problems. If you have read at least 85% of the Piazza posts (as recorded by Piazza, so you must read them through the website) every time I check during the semester, you will earn ten extra credit points on your final exam grade. I will check your progress reading Piazza randomly, so make it a habit to read Piazza each day.
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 regularly checking both your CS email and your email officially registered with UT 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 course staff 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. If you do not, a response to your email may be delayed indefinitely.
Facebook, text message, twitter, calling a mobile phone, or other forms of informal communication: None of these should ever be used to communicate with course staff regarding 439 material.
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, so please check it throughout the semester.
Required Effort: The workload for this course is heavy. There are readings, five projects, twelve problem sets, 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 Wednesday, 2/22, and Wednesday, 4/5.
The final will be cumulative, but it may be more heavily weighted towards material that has not yet been tested. The final exam will be at a UNIFORM time with the other sections of CS439 and not the time listed on the registrar's tentative schedule. The date could be as late as Tuesday, May 16. The Registrar usually publishes uniform final exam dates in early April.
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.
Discussion Section Participation: Discussion sections are designed to enhance understanding of the concepts and help prepare for the exams. Additionally, discussion sections are the only place where projects are introduced and explained. The first half of the discussion sections will focus on reviewing lecture, discussing the problem set assigned that week, and working an additional problem. The second half of the discussion section will focus on the projects.
There will be a written problem set assigned for each discussion section, which you must work before discussion section and will be discussed and reviewed during section. It is essential that you complete the problem set beforehand to maximize the benefit you get from the discussion, so you can contribute to the discussion, and so you earn your discussion section credit. The problem sets will be posted to the schedule on the course website.
We will typically rate your discussion section particpation on a "OK/Not-OK" basis, where "OK" means that you made a credible effort to solve the problem set (even if you make a mistake), participated in the discussion, and remained for the entire section. We do reserve the right to grade for correctness as well. To receive credit for discussion section, you must:
As in lecture, the use of any electronics during discussion section results in a loss of credit for that discussion.
The lowest two discussion section scores will be dropped.
Projects: There will be five programming projects during the semester. The due date for each project will be clearly stated in class, on the project web page, and on the schedule. Plan to start early since debugging systems 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. For your first project where your average ranking is Marginal or less you will receive a warning. For every project after that where your average ranking is Marginal or less, your final course grade will be reduced by a letter grade.
All projects must be submitted using Canvas. 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 Canvas.
Projects must compile and be submitted in the correct format. Projects that do not compile or are in the wrong format will receive a 0. All other given turnin instructions must also be followed exactly.
Finally, all groups (and individual group members) must have a working Project 2 before moving on to Project 3. Groups may either meet this requirement by submitting a working project before the deadline or groups may meet with course staff to demonstrate a working project after the deadline. A reasonable amount of assistance will be provided. This policy does mean that a student may not leave a group that does not have a working Project 2 to work with a group that does. Once a working Project 2 has been submitted, students may join whichever group they wish for the remaining projects.
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, and you may use no slip days on the final 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.
Note that each project has two pieces (the code and the design document), but that it is considered one assignment, so that if you subit both peices two days late, you lose two slips dats, not four.
In the case of group and pair programming, each member of the team must have enough slip days to cover the submission of the project code. So if the team submits the code 2 days late, each team member must have two slip days remaining to use and each team member will lose two slip days. Design documents are completed individually, and so the student submitting the design document must have enough slip days to cover any deadline extensions and only that student will be docked slip days.
To use slip days, you only need to submit the assignment late and indicate that you used a slip day in the project README or the design document header, whichever is appropriate. You do not need to email the instructor or the TA unless specifically requested to do so.
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%.|
|Discussion Section Participation||8%||To receive discussion section participation credit, you must attend your discussion section with your name tent displayed, arrive with the assigned problem set completed, participate in the discussion, and stay until dismissed by the TA. The lowest two discussion section credits 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 may be more heavily weight towards the last third of the course. Closed-book.|
The course uses the plus/minus grading scale and will likely be graded on a small 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. I guarantee that anyone who gets a grade of 90% or more of the total points will get at least 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 the course 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 complaint to the grader.
For project grades and discussion section participation credits, you must submit an email complaint to the grader within one week of the date on which we first attempted to return the graded work to you. For assignments where your feedback is given electronically, the deadline is one week from the time the grade became available on Canvas. 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 we only unmute assignments on Canvas when all grades are entered. If an assignment is unmuted and you do not have a grade at all, you should be worried and submit a grade change request following the above guidelines.
For exam grades, complaints must be written and returned with your copy of the exam before you leave the discussion section in which we return the exam to you. Your complaint must explain why your answer was not graded according to the given rubric. Complaints not following this format will not be considered, not will complaints that argue the rubric (see below about which grade discussions are inappropriate).
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 problem sets.
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: (1) sit, design, and program together at least 80% of the time, and (2) 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 or group, please request permission from the instructor and await further instruction.
If your partner falls out of communication with you, it is your responsibility to notify the course staff.
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. 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, including stackoverflow and other such sites. If you have any doubts about what is allowed, ask the instructor.
Additionally, if you are repeating the course you may NOT reuse any code or assignments. All submitted work must be new and original.
Plagiarism detection software will be used on various assignments and homeworks 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. Note that, "I actually didn't participate in that project because I was doing x, y, or z instead." is not considered a valid excuse---instead it is a type of cheating, since you were then prepared to take credit for work that was not yours.
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, Andy Wang, John Bell, and Zero Assurance Recovery.
Special thanks to the Stanford Computer Science Department for the use of Pintos, an instructional operating system.
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.