CMPSCI 377: Operating Systems (Fall 2006)


Course Description

In this course we examine the important problems in operating system design and implementation. The operating system provides a well-known, convenient, and efficient interface between user programs and the bare hardware of the computer on which they run. The operating system is responsible for allowing resources (e.g., disks, networks, and processors) to be shared, providing common services needed by many different programs (e.g., file service, the ability to start or stop processes, and access to the printer), and protecting individual programs from one another. The course will start with a brief historical perspective of the evolution of operating systems over the last fifty years, and then cover the major components of most operating systems. This discussion will cover the tradeoffs that can be made between performance and functionality during the design and implementation of an operating system. Particular emphasis will be given to three major OS subsystems: process management (processes, threads, CPU scheduling, synchronization, and deadlock), memory management (segmentation, paging, swapping), file systems, and operating system support for distributed systems. Assignments: 4 labs in C/C++, 2 exams, 6 or more written homework. Prior experience with C/C++ is helpful.

 

This is an undergraduate-level course; it is meant for CS undergraduate students.  The prerequisites for the course are CMPSCI 187 and (CMPSCI 201 or ECE 232).

 


Course Information

Instructor: Mark Corner

Lecture Time & Place: TTh 2:30-3:45, CMPS 142

Discussion Time & Place: W 11:15-12:05 , ELAB 323

Credits: 4

Instructor: Mark Corner (mcorner@cs.umass.edu), 330 Computer Science Research Bldg

Teaching Assistants:   Vitaliy Lvin (vlvin@cs.umass.edu)

                                               

Office Hours: See Below

 

Newsgroup: http://bb-edlab.cs.umass.edu/cs377/

 

Course web page: http://www.cs.umass.edu/~mcorner/courses/377/

 

Textbook: Operating Systems Concepts, 7th Edition, Silberschatz/Galvin/Gagne (Wait for class before you buy it)

 

Possible Companion Books: C++ For Java Programmers by Timothy A. Budd and C++ for Java Programmers by Mark Allen Weiss

 

Additional Class in C++: CS197C (typically in the spring)
 

 Staff

Mark Corner

 

Vitaliy Lvin

 


Schedule

Midterm
Evening Exam:  Wednesday Oct 25 2006 6:00 PM-07:30 PM  GOES0020  (Goessmann)

Final  Exam: Thursday December 21 1:30 PM HASA0124 (Hasbrouck Lab Addition)

 

Sample Midterm, Review Session Discussion Section Oct. 25

Sample Exam, Review Session TBA

 

Extra Office Hours:

Project 1:

Mark: Saturday 1-3PM CS 330

Vitaliy: Tuesday 5-7PM Edlab

 

Project 2:

Mark: Sunday 1-3PM CS 330

Vitaliy: Tuesday 5-7PM Edlab

 

Project 3:

Mark: TBA

Vitaliy: TBA

 

 

Schedule

 

Monday

Tuesday

Wednesday

Thursday

Friday

9-9:30

 

 

 

 

 

9:30-10

 

 

 

 

 

10-10:30

 

 

 

Office Hours-Mark

CS330

10-11

 

10:30-11

 

 

 

 

11-11:30

 

 

Discussion Section

ELAB 323

11:15-12:05

 

 

11:30-12

 

 

 

 

12-12:30

 

 

 

 

 

12:30-1

 

 

 

 

 

1-1:30

 

 

 

 

 

1:30-2

 

 

 

 

 

2-2:30

 

 

 

 

 

2:30-3

 

Lecture

CMPSCI 142

2:30-3:45

 

Lecture

CMPSCI 142

2:30-3:45

 

3-3:30

 

 

 

3:30-4

 

 

 

4-4:30

 

Office Hours-Mark

CS330

4-5

Office Hours-Vitaly

Edlab

4-6PM

 

 

4:30-5

 

 

 

5-5:30

 

 

 

 

5:30-6

 

 

 

 

 


 

Project Handouts


Resources


Course Requirements

 

The work of this course consists of:

 

 

Attendance

 

Class lectures and discussions are an integral part of this course.  Attendance at both are mandatory, although they are ungraded.  Many helpful hints about the projects and exams will be made in class lecture, so it behooves you to attend.

 

Programming Projects – 50%

Four group projects will be assigned during the term (5%, 15%, 15%, 15%), each of which will require a substantial time commitment on your part. Many students find the work load in this course to be heavy.  The most common reason for not doing well on the projects is not starting them early enough. You will be given plenty of time to complete each project. However, if you wait until the last minute to start, you may not be able to finish. Start early and plan to have it finished a few days ahead of the due date—many unexpected problems arise during programming, especially in the debugging phase. The EDLAB can become quite crowded as deadlines approach, making it difficult to get a computer. You should plan for these things to happen. Your lack of starting early is not an excuse for turning in your project late, even if some unfortunate situations arise such as having your computer crash.  There are many sources of help on which you can draw. Most questions can be submitted to the teaching staff and your fellow classmates via electronic news. These will typically be answered within the day, often more quickly during working hours. However, some types of questions cannot be answered without seeing your project. If you have detailed questions on your program, speak to one of the teaching staff in person during office hours. Students are also encouraged to help one another on the course concepts (but not the implementation of the projects). One of the best ways for you to make sure that you understand a concept is to explain it to someone else. Keep in mind, however, that you should not expect anyone else to do any part of your project for you. The project that you turn in must be your own.

 

Group policies

 

All projects in this course are group projects. You must form a group of 2-3 students for these

projects.  To declare a group’s membership, send e-mail to mcorner@cs.umass.edu with the group members’ names and email addresses. The group declaration deadline is Feb. 9 (shortly after Project 0 is assigned). After this date, we will randomly combine remaining students into groups of 2 or 3. It is in your best interests to choose your partners carefully. You should discuss topics such as prior experience, course background, goals for this course, workload and schedule for this semester, and preferred project management and work style. Make sure you can find several blocks of time during the week to meet to discuss or carry out the project.  Students are expected to participate wholly in their group to the benefit of the entire group. All group members should be familiar with all aspects of the project, irrespective of their role on the project. We expect all group members to contribute their fair share, and we expect to assign the same project grade to all members of a group.  Group members will evaluate the contributions of other group members after each project. Members who contribute less than their share may receive a lower grade on the project; non-contributing members will receive a zero. In case of disputes regarding contribution, one of the teaching staff may interview group members on the project design and implementation.

 

Students may be “fired” from a group by the majority vote of the remaining members. The procedure for this is as follows: (1) documented “gentle warning” of risk of firing in e-mail, with cc to all group members and to mcorner@cs.umass.edu, with cause and specific work required to remain in group; (2) allow at least 72 hours for compliance; (3) send documented statement of firing in e-mail, with cc to all group members and to mcorner@cs.umass.edu. Fired group members must actively pursue and obtain membership in another group. Students that don’t get hired or cannot find partners will need to work alone. So, it is in your interest not to get fired by your group.  Managing group dynamics and using each group member’s time and talents effectively can be as difficult as solving the project. We are happy to offer advice on how to handle these issues. Be open and candid with your group about any potential problems early on so that your group can plan around such problems and not fall behind. A sure way to make your group upset at you is not finishing your part of the work at an agreed-upon deadline and not informing them about the problems early enough for them to help.

 

Turning in projects

 

You will be submitting your projects electronically by running a program called submit377. Projects are due at 6:00 pm on the due date. To account for short-term unexpected events like computer crashes, submission problems, and clock skew, we will allow 3 hours of slack and accept projects until exactly 8:59 pm. Sometimes unexpected events make it difficult to get a project in on time. For this reason, each group will have a total of 3 free late days to be used for projects throughout the semester. These late days should only be used to deal with unexpected problems such as illness. They should not be used simply to start later on a project or because you are having difficulty completing the project. Projects received after the due date (assuming that you have no late days left) will receive a zero, even if it is just one second late.  Try to save some late days for the last project. Weekend days are counted in the same way as weekdays (e.g. if the project deadline is Friday and you turn it in Sunday, that’s two days late).

 

Extensions

 

Extension requests (other than the use of free late days) should be made before the original due date.  Extensions will only be granted for medical or personal emergencies. All extension requests must be accompanied by written verification, for example a written note from your doctor. In most cases, your project group members will be expected to make up the deficit without needing an extension. Extensions are not granted for reasons such as: you erased all your files, the lab was crowded and you couldn’t get a computer, you had other course work or job commitments which interfered, etc.. You can avoid all these problems by starting the projects early and keeping backup files. If you are having trouble understanding the material or designing a program, please come to office hours for help right away.

 

Doing your own project

 

All projects in this course are to be done by your own group. Violation will result in a zero on the project in question and initiation of the formal procedures of the University. We use an automated program and manual checks to correlate projects with each other and with prior solutions.  At the same time, we encourage students to help each other learn the course material. As in most courses, there is a boundary separating these two situations. You may give or receive help on any of the concepts covered in lecture or discussion and on the specifics of C++ syntax. You are allowed to consult with other students in the current class to help you understand the project specification (i.e. the problem definition). However, you may not collaborate in any way when constructing your solution—the solution to the project must be generated by your group working alone. You are not allowed to work out the programming details of the problems with anyone or to collaborate to the extent that your programs are identifiably similar. You are not allowed to look at or in any way derive advantage from the existence of project specifications or solutions prepared elsewhere.

 

If you have any questions as to what constitutes unacceptable collaboration, please talk to the instructor right away. You are expected to exercise reasonable precautions in protecting your own work. Don’t let other students borrow your account or computer, don’t leave your program in a publicly accessible directory, and take care when discarding printouts.

 

Examinations – 50%

There will be two examinations in this course.  One will be given at midterm and one final exam.  The final examination is intended to cover the second half of the class, so it is not cumulative per se, however it is difficult to make a final that is completely independent of the first half of the class.  There will be review sessions given in the discussion sections for each of the exams.

 

Regrading Policy

 

Regrading on exams will only be done after a written explanation of why the regrade is needed.  With the exception of simple addition errors on our part, we will regrade your ENTIRE exam.  You grade may or may not change, and it may go up or down.

 


 

Course Schedule

 

This schedule is subject to change as the course develops; changes will be announced in class.

 

Week

Tuesday

Thursday

Notes

Sep. 3

No Class

Intro/C++

Th: Project 0 Out

Read: C++ document, 1.1, 1.2

Sep. 10

C++

C++/OS

T: Group Membership Due

Sep. 17

Threads/Conc

No Class

(out of town)

T: A/D Deadline

Th: Project 0 Due, Project 1 Out

Read: 4.1, 5.1, 7.1

Sep. 24

Threads/Conc

Threads/Conc

Read: 7.2-7.7

Oct. 1

Threads/Conc

Threads/Conc

Read: 8.1-8.4, 8.5.3, 6.1.2-6.3.4

Oct. 8

Threads/Conc

Threads/Conc

Read: 9.1-9.1.2, 9.2-9.4.4.1

Oct. 15

Address Spaces

Address Spaces

M: Drop with a W,

Th: Project 1 Due, Project 2 Out, Read: 9.5-9.5.4, 10.3-10.4.5.1

Oct. 22

Address Spaces

Distributed Computing

 

Oct. 29

Distributed Computing

Distributed Computing

W: Drop With W

Read: 15.1-15.4

Nov. 5

Distributed Computing

File Systems

Read: 15.4-15.9

Nov. 12

File Systems

File Systems

Th: Project 2 Due, Project 3 Out

Read: 11

Nov. 19

File Systems

No Class (Tgv.)

Read: 12.1-12.6

Nov. 26

Security

Security

Read: 19.1-19.3, 19.7

Dec. 3

Security

Current Topics

 

Dec. 10

Current Topics

No Class

Th: Project 3 Due, F: Exams Begin

Dec. 17

No Class

No Class

F: Exams End

 

 

 

 

 

 

 

 

 

Total: 26 Classes

 

OS and Intro: 1 Class

C++: 2 Classes

Threads and Concurrency: 7 Classes

Address Spaces: 3 Classes

Distributed Computing: 4 Classes

File Systems: 4 Classes

Security: 3 Classes

Current Topics: 2 Classes


 

Policy on Collaboration and Cheating

 

 

This all may sound pedantic or even harsh, but I have no sympathy for those that gain unfair advantages over their classmates and misrepresent themselves.

 

All projects in this course are to be done by you. Violation will result in a zero on the project in question, probable failure in the course, and initiation of the formal procedures of the University. We use an automated program and manual checks to correlate projects with each other and with prior solutions. At the same time, we encourage students to help each other learn the course material. As in most courses, there is a boundary separating these two situations. You may give or receive help on any of the concepts covered in lecture or discussion and on the specifics of language syntax. You are allowed to consult with other students in the current class to help you understand the project specification (i.e. the problem definition). However, you may not collaborate in any way when constructing your solution—the solution to the project must be generated by you working alone. You are not allowed to work out the programming details of the problems with anyone or to collaborate to the extent that your programs are identifiably similar. You are not allowed to look at or in any way derive advantage from the existence of project specifications or solutions prepared elsewhere.  You may not use other people’s test cases with your own program.  You may not look at their code.  You may not purchase solutions off the internet, or hire people to code your project. 

 

If you have any questions as to what constitutes unacceptable collaboration, please talk to the instructor right away. You are expected to exercise reasonable precautions in protecting your own work. Don’t let other students borrow your account or computer, don’t leave your program in a publicly accessible directory, and take care when discarding printouts.

 

After this class has ended do not distribute your solution to anyone taking this class here, or anywhere else.  As these projects take considerable effort to design, we reuse these projects from year to year.  If we are forced to create new projects each year, they will invariable be much less refined, frustrating, and less educational than the current ones.  Showing your solution to another student is considered facilitating dishonesty and you will be referred to the Academic Honesty Board.  This can result in holding up your graduation, or having a notation put on your transcript.

 

Acts of cheating and plagiarism will be reported to the University Academic Honesty Board. You are responsible for knowing, and will be held to, the University Academic Honesty Policy.   This policy is available online:

 

http://www.umass.edu/dean_students/code_conduct/acad_honest.htm

 

Discussion of course material is not considered cheating and is strongly encouraged. If you receive substantial help from another person you must acknowledge them in your work. If you use any published or unpublished source in any of your own work, you must give full citation.  If you have questions about these policies please see the instructor.