Syllabus v1.0.1
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 / EE 128!
This course is for undergrad and graduate CS and ECE 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 EE 14 before attempting CS 111 / EE 128. Grad students may have taken an undergraduate course in “intro to computer systems”, “computer organization”, or “microprocessor design” at another school. 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 EE 14 (Embedded Systems), or equivalent computer organization course from another school
- Graduate Students:
- The registration allows “or graduate standing” and will not strictly check these prerequisites because many grad students have taken equivalent courses at other schools, rather than these exact courses at Tufts, and the registration system cannot know about courses taken at other schools. However, it is critical for your success in this class that you have the knowledge from both these classes.
- If you are unsure of whether your previous coursework is sufficient (or if you’ve learned this material outside of official coursework), you are welcome to talk to me about it and I’ll help figure it out. We’ll also discuss it as a class in the first week of the semester, so you can check your knowledge then.
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. (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 be held in-person; there is no “remote option” and there are no exceptions to this policy.
- Tuesdays & Thursdays, 12:00 – 1:15 PM
- Joyce Cummings Center (JCC) 160
The first class will be Thursday, Jan. 19, 2023. The last day of class will be Thursday, April 27, 2023.
Important schedule notes:
- Class will not meet on Thursday, Feb. 23 (go to your Monday scheduled classes instead)
- The instructor will be out of town on Thursday, March 16, but we may still have a guest lecture, review session with the TAs, or something like that instead of normal class.
- Class will not meet on Tuesday, March 21 or Thursday, March 23, due to spring break
Instructor & TAs
Dave Lillethun is the instructor. TAs are BJ Stubbs and Jake Sturim.
Office hours and contact information will be posted in Canvas.
Weekly Flow
Each week will proceed as follows:
- You will prepare for the week’s class by doing the following activities at home. These will be due at 12:00 noon on Monday (24 hours before Tuesday’s class starts).
- Review the prior knowledge statement, and review using the provided materials, if necessary
- Reading Assignments
- Respond to a Discussion Question
- Submit a Question you have about the reading content, or a “Muddiest Point” (something you found confusing or would like clarified, even if it isn’t phrased as a question)
- We will address common questions and muddy points in class. (Thus submitting 24 hours before class, so I have time to read these and prepare for class.)
- ungraded Homework for practice at home
- any Programming Assignment or take-home Test that is being assigned that week
- Attend class on Tuesday and Thursday
- Work on the ungraded practice Homework (feel free to collaborate, since it’s not graded!)
- Practice questions will be released at the beginning of the week
- Answers will be released at the end of the week
- These are not collected, but you can use the answers to check your own work
- Feel free to ask the course staff if you have any questions! (office hours, Piazza, etc.)
- Programming Assignments, Tests, or Learning Reflections due that week will be due Thursday 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.)
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 according 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, test, or learning reflection. 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 him 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.
Learning Reflections and Class Preparation activities (Discussions and Questions/Muddiest Points) will be graded as Complete or Incomplete, based on having made a satisfactory attempt.
| D | C | B | A | |
| Programming Assignments that meet (or exceed) expectations | 2 | 3 | all (4) | 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 * | none * | 20% |
| Learning Reflections that are completed | 0 | 1 | 2 | 2 |
| Class Preparation activities (Discussions & Muddiest Points) that are completed | 12 | 15 | 17 | 20 (of 26) |
Here is what you need to do to earn each letter grade. You must meet all of the criteria for a letter grade in order to get that grade.
* Every two questions that score Exceeds Expectations will give a bonus Meets Expectations point (i.e., two Exceeds Expectations questions == three Meets Expectations questions).
(+) 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 and Retake Policies
All the programming projects and learning reflections will allow you to “Revise & Resubmit”. This means that if you do not “exceed expectations” (or get a “complete”) 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 nine (9) 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. By continuing to take this course, you indicate your agreement to follow all the policies. 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.
v1.0.1: Fixed an incorrect pronoun.
Dave Lillethun, Ph.D. 