Syllabus
Staff
Instructor
Teaching assistants
- Bobby Chen
- Rajath Subramanyam
- Yang Xu
- Fan Yang
Lab assistants
- Nicholas Bachmann
- Alec Benzer
- Sarah Dong
- Cyrus Eduljee
- Will Hennessy
- Bhuwan Khattar
- Hyun Bin Lee
- Zitian Liu
- Sammy Rabkin
- Zhengqi Yang
- Xiaocheng Yuan
Getting help
For all technical and class related questions, go to Piazza.
For personal questions only, email cs241help-sp14@cs.illinois.edu.
Textbook
There is no required textbook for CS 241.
Some useful textbooks include:
- William Stallings, "Operating Systems: Internals and
Design Principles", Fifth Edition.
- Kay A. Robbins and Steven Robbins, "UNIX Systems
Programming: Communication, Concurrency, and Threads".
- Randal E. Bryant and David R. O'Hallaron, "Computer
Systems: A Programmer's Perspective".
- Operating Systems: Internals and Design Principles,
Fifth Edition by William Stallings, Prentice Hall ISBN
0-13-147954-7.
- UNIX
Systems Programming: Communication, Concurrency and
Threads by Kay A. Robbins and Steven Robbins, Prentice
Hall ISBN 0-13-042411-0
- Modern Operating Systems (Second Edition), Andrew
S. Tanenbaum, Prentice Hall, 2001
- Applied Operating System Concepts, Silberschatz,
Galvin, Gagne, John Wiley & Sons, Inc.
- Operating System Concepts, Silberschatz and
Galvin
- The Design of the Unix O.S., Maurice J. Bach.
- The UNIX System, S. R. Bourne.
- The Mythical Man Month, F. Brooks.
- Operating System Design, D. Comer, T. Fossum.
- Internetworking with TCP/IP, Doug Comer.
- An Introduction to Operating Systems, Harvey M.
Deitel.
- Operating Systems: Design and Implementation,
Andrew S. Tanenbaum.
- The Logical Design of Operating Systems, Alan
Shaw.
- Operating Systems, Internals and Design
Principles, William Stalling.(3rd Edition).
Course Overview
A computer needs an operating system to manage its resources
and provide support for common functions such as accessing
peripherals. There are two categories of "customers" that an
operating system must support. The first category is the
community of users. We have all used computers and you may
recognize operating systems' functions such as creating
folders (directories) and moving files around. These are
examples of operating system support for users. User support
is not the objective of this course. This course addresses
operating system support for the second category of customers;
namely, the programmers. Those are people who write code to
execute on the computer. When you write a program, it may have
to interact with physical hardware (memory, flash storage,
screen, network, etc.). For example, you may want to get input
from a keyboard or mouse, you may want to read some
configuration file stored on disk, you may want to output data
to a screen or printer, or you may want to access a remote
server across a network. The operating system presents common
interfaces for programmers to perform these functions. The
operating system also provides useful abstractions such as
"tasks" (also called processes), "threads", and "semaphores".
You can make the computer multitask by calling the operating
system interface for creating new tasks or new threads. You
can make these tasks coordinate and synchronize by using
operating system semaphores. You can tell the computer the
order in which you want tasks to be executed, which is called
a scheduling policy. Finally, you can manage computer memory
by calling the operating system function for memory
management. System programming refers to writing code that
tasks advantage of operating system support for programmers.
This course is designed to introduce you to system
programming.
By the end of this course, you should be proficient at
writing programs that take full advantage of operating system
support. To be concrete, we need to fix an operating system
and we need to choose a programming language for writing
programs. We chose the C language running on a Linux/UNIX
operating system (which implements the POSIX standard
interface between the programmer and the OS). This pairing of
C and UNIX/Linux is used heavily by software that must provide
high performance and low-level control of the program's
execution. Hence, this course introduces you to systems
programming via the specific case of C over UNIX. By the end
of the course you should be proficient with this programming
environment and should be able to write non-trivial pieces of
software from web server code to your own multiplayer Internet
games. More specifically, after taking this course you should
be able to accomplish the following:
- Identify the basic components of an operating system,
describe their purpose, and explain how they function.
- Write, compile, debug, and execute C programs that
correctly use system interfaces provided by UNIX (or a
UNIX-like operating system).
- Be familiar with important UNIX system calls and invoke
them correctly from within C programs.
- Describe the difference between programs, processes, and
threads.
- Explain the meaning and purpose of process control blocks
and other mechanisms that the operating system uses to
implement the process and thread abstractions.
- Write, compile, debug, and execute C programs that create,
manage and terminate processes and threads on UNIX.
- Define concurrency and explain the problems that may arise
because of concurrent execution of multiple processes or
threads. Explain how these problems can be avoided. Write
code that avoids these problems.
- Define semaphores, mutexes, and other synchronization
primitives, explain their purpose, and describe their
internal implementation.
- Describe possible problems that arise from improper use of
synchronization primitives (such as deadlocks) and present
their solutions.
- Write, compile, debug, and execute C programs that use
UNIX synchronization primitives.
- Describe operating system scheduling and use UNIX
interfaces to set and modify scheduling policy parameters.
- Define UNIX signals and signal handlers, and describe
their use.
- Write, compile, debug, and execute C programs with
processes and threads that interact by invoking and catching
signals.
- Describe, configure, and use operating system timers and
clocks.
- Describe the concepts of I/O devices, files, directories.
- Explain the internal implementation of files systems and
operating system I/O.
- Write, compile, debug, and execute C programs that use
files and I/O on UNIX.
- Describe the machine memory hierarchy, describe its
components such as caches and virtual memory, and explain
memory management mechanisms pertaining to these components
such as paging and segmentation.
- Write, compile, debug, and execute C programs that make
use of memory management functions.
- Explain the concept of DMA.
- Describe the protocols (such as TCP and IP) and interfaces
(such as sockets) used for communication among different
computers.
- Write distributed applications that communicate across a
network.
Grading
Components
- Final Exam (30%): There will be one final exam during
finals week.
- Midterm Exam (25%): Monday, March 10th time:TBD
- Machine problems (45%): There will be 8 Machine
Problems (MPs). MPs will either be one week or two weeks
long. Machine problem solutions must be submitted via SVN by the respective
deadlines. All MPs must be done by individual students, NOT
in groups. Longer MPs are worth a little more
Late policy
- MPs: up to 24 hours, 30% deduction,
with no submissions accepted past 24 hours late.
- Extenuating circumstances: If you observe a
religious holiday that interferes with getting a machine
problem or homework completed, please let the TA know well
ahead of time, i.e., at least one week in advance. Given the
circumstances, we will try to accommodate such requests by
issuing extensions as appropriate, as long as we have been
given at least one week's notice. In addition, we
accommodate special medical circumstances, such as death in
the family or hospitalization, with appropriate
documentation. We cannot accommodate excuses such as "My
laptop died the night before the deadline and I could not
submit".
- MP0 = 3%
- MP1 = 4%
- MP2 = 7%
- MP3 = 5%
- MP4 = 6%
- MP5 = 8%
- MP6 = 6%
- MP7 = 6%
- Total = 45%
Re-grading
After the grades are available, you have 1 week to request a regrade.
If you believe you were not graded
correctly, please help up by asking for regarding during that
window. After 1 week, no more regrade requests will be
honored.
Prerequisites
CS 225, credit or concurrent registration in CS 398 or CS 233
Course Activities
We meet for lectures 11:00 - 11:50 am Monday, Wednesday and
Friday in Room 1404 SC. Lectures cover important operating
system concepts, and their implementation. It is the students'
responsibility to read assigned materials.
You are expected to attend lectures, and will be responsible
for announcements made during lecture, as well as on the cs241
web page, and on Piazza.
There are multiple discussion sessions. You should sign up
for one of the discussion sessions using Banner as soon as
possible.
EWS Machine Facilities
We will be using linux machines, running POSIX system programming interface, in
labs in 1245 DCL, 1265 and 1275 DCL and in 0220/0222 SC (basement). You should make sure that you have
accounts on the EWS machines to do your machine problem
assignments. We recommend that you use a 64-bit EWS machine.
We run our autograders on linux.ews.illinois.edu,
so even if you develop your code elsewhere, you should
test your code on linux.ews.illinois.edu before
submitting and at regular intervals while developing
your code. While the desktop EWS machines run the same OS and
same word size, slight differences have resulted in problems
for buggy code in past semesters.
To access these machines from outside the university, please
use CITES VPN client.
If you want to audit the course and don't have an account,
please speak with the course staff. If you have other problems
relating to the existence of your account, please
email engrit-help@illinois.edu.
Academic honesty and cheating
Cheating is taken very seriously in CS 241. Be sure to
understand the departmental
honor code. Your work in this class must be your own. If
students are found to have cheated (e.g., by copying or
sharing answers during an examination or sharing code for the
project), all involved will at receive grades of 0 for the
first infraction and will be reported to the academic office,
and may receive additional penalties such as a reduction of
one letter grade in the final course grade. Further
infractions will result in failure in the course and/or
recommendation for dismissal from the university.
You are a respected individual in a community of collegiality
and trust. We honor and believe your word. We trust what you
say and will generally not ask for proof. However, with trust
comes responsibility. Violation of trust will not be
tolerated. In particular, acts not befitting this community
such as cheating (e.g., collaboration on homeworks or exams
that are not meant to be collaborative) fall in the category
of violation of trust. Individuals who commit such acts will
lose the privileges of trust and receive grade reductions as
described above.
Your machine problems must be a result of individual work. You
are responsible for protecting your work. In the past,
we had cases of copying solutions from other students without
their knowledge. To avoid having your work copied without your
knowledge, refrain from leaving source code prints lying
around the lab, protect your files, don't give your passwords
to anyone, and enter your passwords in a way that cannot be
seen by others. Do not leave a login session active on an
unattended workstation. Use xlock on the EWS
workstations if you must leave briefly, or use some similar
measure (or log out!) in other labs; remember that it's a
violation of the CSIL policy (and probably the other lab
policies) to leave your workstation unattended for any
extended period of time. Report suspicious behavior to the lab
sitters or the TAs.