Syllabus v1.0
Course Description
What does an operating system do? How do you write programs that interact with the OS? How does it allow allow more than one process to run concurrently? How do you write concurrent programs and avoid “data race” bugs? How does the OS prevent running out of memory, even when the processes require more than the memory hardware provides? How are file systems constructed? How can we avoid complete system failures resulting from small errors (“faults”) in a subsystem? What security features does an OS use to protect running programs and stored data? The answers to all these questions an more will be learned in CS 111!
This course is for graduate CS majors who want to learn how operating systems work, systems-level programming, and related topics like concurrency, synchronization, and fault tolerance.
Students should have completed CS 40 or an equivalent , such as “intro to computer systems”, “computer organization”, or “microprocessor design”, at another school before attempting CS 111. If you are unsure whether a course you’ve taken meets the prerequisite, please contact the instructor.
Learning Outcomes
Upon completion of the course, students should be able to:
- Explain how the mechanisms operating systems use to virtualize hardware work in order to allow multiple processes to run at once
- Explain how the mechanisms and abstractions operating systems use to facilitate program interactions with I/O devices, and particularly disk devices work
- Compare and contrast different policies that operating systems may use to manage resources
- Describe the things that can go wrong in operating systems, and explain how security and reliability mechanisms in operating systems help to avoid these problems
- Develop systems-level programs that interact with the operating system
- Choose and correctly apply system abstractions for concurrent programming
Prerequisites
ALL of the following are required prerequisites for this course:
- CS 15 (Data Structures) or equivalent data structures course from another school
- CS 40 (Machine Structure & Assembly-Language Programming), or equivalent computer organization course from another school
- You do not need to already know the C programming language, but you should be prepared to learn it on your own during the course. (If you have programmed in C++ before, the transition is fairly easy.)
Course Materials
Required Textbook:
- Operating Systems: Three Easy Pieces. Remzi H. Arpaci-Dusseau and Andrea C. Arpaci-Dusseau. Arpaci-Dusseau Books. August, 2018 (Version 1.00)
- Available free online here. Links to buy a hard copy are also on that page, if you want one, but it is not required – the free online PDFs are sufficient.
Recommended Textbook:
- Kernigham and Ritchie. The C Programming Language, second edition. Prentice-Hall.
- ISBN 13: 978-0131103627
- This course is not about learning to program in C, but you will have to program in C for the assignments. If you are not already familiar with C/C++ then this book may be helpful to you. (If you are familiar with C++ but not C, less so, but it may still be useful.) It is not required, but you should decide if it will be worthwhile for you.
- This is also a “classic” book. So if you do buy a copy, it is one that a computer scientist may proudly display on their bookshelf forever.
You will be given access to the CS department Linux server to work on for programming assignments and other purposes in this class. You should have access to a laptop or other suitable computer with an Internet connection that you can use to connect (via SSH) to the server, as well as to join class sessions using Zoom. (On Mac or Linux, there is a built-in command line command to SSH; on Windows, I recommend using the free program PuTTY.)
Class Times & Location
This class will have one synchronous session every week, in addition to the asynchronous content.
- Tuesdays, 7:30 – 9:00 PM (EDT)
- Check your timezone! All times for this class will be posted in Eastern Time (U.S. East Coast / Boston time)
- Zoom link in Canvas
The first synchronous class will be Tuesday, 5/30/2023, but Canvas will be opened in advance of that date and there will be asynchronous material you should look at before our first synchronous meeting.. The last day of class will be Tuesday, 8/8/2023, although time past then will be allowed for completing class work. (Exactly when the final deadline for class work will be is Friday, 8/11/2023.)
Important schedule notes:
- We will meet for class at 7:30 PM EDT on Wednesday, July 5, since that Tuesday, July 4 is a school holiday. Class will be recorded for anyone who isn’t able to attend, but your live participation on July 5 is strongly encouraged.
- Class will not be canceled due to campus closures on account of snow, or any other reason, since this is an online class.
Instructor
Hifza Khalid is a Part-time Lecturer and a Ph.D. Candidate at Tufts University. Her research interests are in operating systems, machine learning, datacenter workloads and capacity planning.
Office Hours: Wednesdays, 2-3 pm ET
Zoom link for office hours and contact information will be posted in Canvas.
Weekly Flow
Each week will proceed as follows:
- The prior Friday, course materials will be posted (if they are not already posted farther in advance), including:
- Reading Assignments
- Lecture Videos
- ungraded “Quiz” questions associated with the Lecture Videos
- ungraded Homework for practice at home (feel free to collaborate, since it’s not graded!)
- any Programming Assignment or take-home Test that is being assigned that week
- Complete at least the assigned lecture videos (and associated “quiz” questions) prior to the synchronous class for the week.
- We recommend also doing the reading assignment before the synchronous class, but if you are unable to do both then watching the videos before class will be more important. However, you should still catch up on the readings later, in that case.
- Attend the synchronous class on Tuesday live using Zoom. (Zoom link is in Canvas.)
- Answers to the ungraded Homework will be posted on Friday at the end of the week
- Programming Assignments or Tests due that week will be due Sunday night
- There will only ever be one Programming Assignment xor Test due in a week (never both), and most (but not all) weeks will have one due. (Weeks when none are due are good times to catch up on resubmissions — refer to the revise & resubmit policy below.)
Notice that the release schedule and deadlines mean that each weekend, you will have access to finish things due for the week that is just ending as well as access to get started on the work for the upcoming week, so you have maximum flexibility to plan your time. Of course, materials will also be available throughout the week, so if you prefer to work during the week instead of on weekend, you should be able to budget your time that way too. The important thing is that you have a plan for how you’ll spend your time and complete the work. Taking advantage of the flexibility to always wait until you have to do something because if you wait any longer you’ll miss the deadline is not going to produce good results in this class.
Assessments
Programming Projects
There will be four (4) significant programming projects, all of which must be written in the C programming language. You will be given at least 2 weeks to complete each one, and you should anticipate taking that long to complete them, so budget your time accordingly and do not wait to start. These programming assignments must be completed individually, according to the “plagiarism & collaboration” policy below. You will be allowed to revise and resubmit programming assignments after receiving feedback on them, according to the “revise & resubmit” policy below.
Tests
There will be five (5) take-home tests that you will work on at home. Test content is cumulative, so every test may ask about material from the beginning of the course up to the week before the test is due. (Tests will never ask about material from the week the test is due, since you haven’t had enough time to practice it yet, except the last week of the course when we don’t really have any choice because the semester is ending.)
Each question will be graded separately (rather than combining them into a single grade for the whole test), so in a sense it’s best to think of each question as a separate assignment. Each question’s grade will be applied towards your final course grade (so each test question has equal weight towards your course grade, rather than each test having equal weight, regardless of the number of questions on the test). However, a single question may have multiple parts (e.g., “part (a)”, “part (b)”, etc.). These questions must be completed individually, according to the “plagiarism & collaboration” policy below.
Late Work Policy
In this class, each students starts the semester with 10 “late tokens” that are each worth an extra day (24 hours) on an assignment — programming assignment or test. There are no penalties for lateness as long as you use a sufficient number of late tokens. If you will not have work completed by the deadline, then email the instructor (contact information is in Canvas) before the deadline and tell her how many extra days you need. A corresponding number of late tokens will be deducted. You don’t need to provide any excuses, just the new date when you will submit the work. As long as you send that email before the assignment deadline, your late submission will be graded for full credit. (However, if there is an emergency situation that makes it impossible or unreasonable to contact us before the deadline, then just send the email as soon after the deadline as is reasonable.)
Course Grades
Each test question or programming assignment will not be given a percentage score or letter grade, but rather will be rated as “Exceeds Expectations”, “Meets Expectations”, “Not Yet (Meeting Expectations)”, or “Not Assessable” (“N/A” for short). Canvas also may show “Not Submitted” (or “N/S” for short) for an assignment. These mean the following:
- Exceeds Expectations – This assessment shows that you have significant proficiency in the relevant topic, beyond the minimum expected by the course learning expectations.
- Meets Expectations – This assessment shows that you have some proficiency in the relevant topic, in line with the course learning expectations.
- Not Yet Meeting Expectations – This assessment shows some knowledge but does not yet demonstrate full proficiency in the topic.
- Not Assessable – This assessment is too incomplete to accurately assess whether you have met expectations or not, or it shows little evidence of knowledge or skills. This could be, for example, a question in which not all parts were attempted fully, or a programming assignment in which not all features have a reasonable attempt to implement them, or that does not compile or crashes every time it is run.
| D | C | B | A | |
| Programming Assignments that meet (or exceed) expectations | 1 | 2* | 3* | all (4) |
| Programming Assignments that exceed expectations | none (+) | none (+) | none (+) | 2 (+) |
| Tests, percentage of all questions that meet (or exceed) expectations | 65% (-) | 75% (-) | 85% (-) | 90% (-) |
| Tests, percentage of all questions that exceed expectations | none | none | 20% | 40% |
* In addition, all other programming assignments must have been fully attempted. That is, even though some may be Not Yet Meeting Expectations, all programming assignments must have been submitted, compile correctly, and the source code must show an earnest attempt at implementing all functionality of the program (no major components may be left unattempted).
(+) Students who meet all the criteria for a letter grade, plus at least one additional programming assignment at the Meets Expectations level or Exceeds Expectations level than required for that letter grade, will receive a plus (+) on their grade. (e.g., B+ for 1 assignment exceeding and 3 meeting, or C+ for all 4 meeting expectations but test questions not being enough for a B)
(-) Students who are within 5% (percentage points) of meeting the required number of test questions meeting or exceeding expectations, but who also meet all the programming assignment requirements for a letter grade, will receive that letter with a minus (-), rather than the next lower letter. (e.g., meeting expectations on all programming assignments but only 80% of questions is a B-, and meeting expectations on 3 programming assignments but only 60% of test questions is a D-, because it’s withing 5% of a D but not within 5% of a C)
Students who do not meet the criteria for at least a D- will receive an F.
Revise & Resubmit Policy
All the programming projects will allow you to “Revise & Resubmit”. This means that if you do not exceed expectations on your initial submission of the assignment, once you have received feedback on your assignment, you may work on improving it (i.e., revise it) and then resubmit it to be graded again. Only the grade on the last submission of each assignment counts towards your course grade. This allows you to keep working on many of the assignments until you succeed.
(Note: Please do not submit work that you know will not at least meet expectations and count on being able to resubmit to improve it. See the “Late Work Policy” above – there is no need to “game” the resubmission process to get more time.)
Keep in mind that if you have some assignments that meet expectations (so you could try to exceed expectations on a resubmission) and others that are not yet meeting expectations, it’s typically better for your grade to work on improving the ones that are not yet meeting expectations to get them up to meeting expectations.
Revising & resubmitting is for programming assignments only. You may not revise test answers after they have been graded. (However, before the test due date, you are free to go back and update your answers and we will just grade the last submission.)
There are some restrictions on resubmissions, as follows:
- We will only grade one resubmission per student per week. If you resubmit more than one assignment at a time, we will grade one that week, the next one the next week, and so on. If you resubmit more assignments than there are weeks remaining in the semester, then we will only grade as many of them as there are weeks left.
- i.e., Resubmit regularly through the semester; do not wait until the last few weeks to try and resubmit everything!
- You may not resubmit until you have received feedback on your assignment. (If you know your first attempt isn’t going to be good enough before you even see our feedback, then see the Late Work Policy above.)
- You start the semester with eight (8) resubmission attempts. Each time you resubmit an assignment, you spend one (1) of your attempts to do so. Resubmitting an assignment multiple times will require an attempt for each resubmission. (For example, if you resubmit a programming assignment, the resubmission still doesn’t Meet Expectations, and you revise and resubmit again, then that would cost you two (2) attempts – one for each resubmission.)
Course Policies
Students in this class are responsible for reading, understanding, and following all of the course policies listed here. If there is any policy that you do not understand, please ask. Ignorance will not be accepted as an excuse for violating any policies.
Changes
This syllabus and any policies for this course are subject to change during the semester in response to changing conditions. Such changes are at the sole discretion of the course instructor. If any changes are made, the appropriate documents will be updated and the change will be announced to the entire class in a timely fashion.
This document has a version number at the beginning to help you tell when changes have been made. When there is a new version, the changes that were made will be listed in the following Change Log. (This may help, for example, so you don’t need to re-read the entire document just to find a small change.)
Change Log
v1.0: Initial version.
Dave Lillethun, Ph.D. 