Instructor

• Wade Fagen, 2215 Siebel Center

Teaching assistants

• Paul Bissonnette
• Bobby Chen
• Hongyang Li
• Reza Shiftehfar

Lab assistants

• TBA

For all technical and class related questions, go to Piazza.

For personal questions only, email cs241help-fa13@cs.illinois.edu.

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.
• OS Book Resource Web Site: Animations, Pseudocode, pdfs, UNIX, Windows, Bibliography, Standards
• Student Resource Web Site: Help for students — math, coding, writing aids, good practices
• UNIX Systems Programming: Communication, Concurrency and Threads by Kay A. Robbins and Steven Robbins, Prentice Hall ISBN 0-13-042411-0
• Programming Resource Web Site
• 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).

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.

Components

• Final Exam (30%): There will be one final exam during finals week.
• Midterm Exam (20%): There will be an evening midterm on Monday, October 14, 2013, 7:00 - 9:00 pm.
• Machine problems (50%): There will be 9 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.
• MP0 = 3%
• MP1 = 3%
• MP2 = 7%
• MP3 = 5%
• MP4 = 5%
• MP5 = 6%
• MP6 = 6%
• MP7 = 7%
• MP8 = 8%

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".

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.

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.

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.

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.