This is a undergraduate-level course;
it is meant for CS undergraduate students.
The prerequisites for the course are CMPSCI 187 and (CMPSCI 201 or ECE
232).
Instructor: Mark Corner
Lecture Time & Place: TTh 9:30-10:45,
LGRT 101
Discussion Time & Place: W 10:10-11 , LGRT 101
Credits: 4
Instructor:
Teaching Assistants:
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
Staff
|
|
|
Schedule
Midterm Evening Exam: Thu Mar 16 2006 06:30
PM -08:30 PM ELAB0303
Final Exam: Fri May 19 2006 4-6 LGRT 101
Sample Midterm,
Review Session in Discussion Section
Sample Exam, Review
Session TBA
Extra Office
Hours:
Project 1:
Mark: TBA
Brendan: TBA
Project 2:
Mark: TBA
Brendan: TBA
Project 3:
Mark: TBA
Brendan: TBA
|
Schedule |
|||||
|
|
Monday |
Tuesday |
Wednesday |
Thursday |
Friday |
|
9-9:30 |
|
|
|
|
|
|
9:30-10 |
|
Lecture LGRT 101 9:30-10:45 |
|
Lecture LGRT 101 9:30-10:45 |
|
|
10-10:30 |
|
Discussion Section LGRT101 10:10-11 |
|
||
|
10:30-11 |
|
|
|||
|
11-11:30 |
|
Office Hours-Mark CS330 11-12 |
Office Hours- Brendan Edlab 11-12 |
|
|
|
11:30-12 |
|
|
|
||
|
12-12:30 |
|
|
|
|
|
|
12:30-1 |
|
|
|
|
|
|
1-1:30 |
|
|
|
|
|
|
1:30-2 |
|
|
|
|
Office Hours- Brendan Edlab 1:30-2:30 |
|
2-2:30 |
|
|
|
Office Hours-Mark CS330 2-3 |
|
|
2:30-3 |
|
|
|
|
|
|
3-3:30 |
|
|
|
|
|
|
3:30-4 |
|
|
|
|
|
|
4-4:30 |
|
|
|
|
|
|
4:30-5 |
|
|
|
|
|
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 |
|
Jan. 29 |
OS |
C++ |
T: Project 0 Out Read: C++ document, 1.1, 1.2 |
|
Feb. 5 |
C++ |
Threads/Conc |
T: Group Membership Due |
|
Feb. 12 |
Threads/Conc |
Threads/Conc |
T: Project 0 Due, Project 1 Out Read: 4.1, 5.1, 7.1 |
|
Feb. 19 |
No Class-Fake Monday |
Threads/Conc |
M: A/D Deadline Read: 7.2-7.7 |
|
Feb. 26 |
Threads/Conc |
No Class (Mark out of town) |
Read: 8.1-8.4, 8.5.3, 6.1.2-6.3.4 |
|
Mar. 5 |
Threads/Conc |
Address Spaces |
Read: 9.1-9.1.2, 9.2-9.4.4.1 |
|
Mar. 12 |
Address Spaces |
Address Spaces |
M: Drop with a DR, T: Project 1 Due, Project 2 Out, Read: 9.5-9.5.4,
10.3-10.4.5.1 |
|
Mar. 19 |
No Class (SB) |
No Class (SB) |
|
|
Mar. 26 |
Distributed Computing |
Distributed Computing |
W: Drop With W Read: 15.1-15.4 |
|
Apr. 2 |
Distributed Computing |
Distributed Computing |
Read: 15.4-15.9 |
|
Apr. 9 |
File Systems |
File Systems |
Read: 11 |
|
Apr. 16 |
File Systems |
File Systems |
T: Project 2 Due, Project 3 Out Read: 12.1-12.6 |
|
Apr. 23 |
Security |
No Class |
Read: 19.1-19.3, 19.7 |
|
Apr. 30 |
Security |
Security |
|
|
May 7 |
Current Topics |
Current Topics |
|
|
May 14 |
Current Topics |
No Class-“Reading” Day |
T: Project 3 Due, Fri: Exams Begin |
|
May 21 |
|
|
F: Exams End |
|
May 28 |
|
|
|
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/rights/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.