Study Guide

In this course you will encounter and learn to understand the use of concurrency in both of these contexts.

This document and the other web-based materials were originally written primarily for distance learning students. This version of the document has been reduced in content for on-campus use.

Suggestions on how this study guide might be improved are welcome, and will be taken account in revisions to the on-line version of the guide during the semester.

The prerequisites for this course (see the list of prerequisites in the Syllabus) imply a high level of computer programming skill and knowledge, including experience using the C++ or C language and the Unix operating system. In addition, you are expected to have some general computer word processing skills. You should have mastered these skills in previous courses.

To succeed in this course you will need to organize and budget your time. Since individuals will start with different sets of prior knowledge and work at different speeds, no one can tell you exactly how long you will need to spend on each activity. You will have to find out what works for you.

The following is an example a weekly time budget that might work for one student, for non-exam weeks:

• 1 hr: Read quickly through the readings in the text that are assigned for the week. If you can't read it all, skip over the parts that bog you down. The objective is to get the big picture, along with as much of the the details as you are able in a limited amount of time. Make a note of any parts that are unclear.

• 4 hrs: Go to classes. Ask questions about any parts that were unclear from the reading, and still seem unclear.

• 2 hrs: Review the on-line lecture notes. Refer back to the textbook for more detail on the parts that are covered by the text. If you find a question in the notes, it may be followed by the answer but try to answer it for yourself before you go on to read the answer. Read through example programs to make sure you understand why they work. Use the on-line Unix man-pages and other web links to puzzle out the effects of any Unix system calls that are not clear to you. Mark down any questions you have left, and ask them in class or use e-mail to get clarification.

• 1 hr: Take the weekly on-line quiz.

• 12 hrs: Work on the current programming assignment. If you have finished that, get started on the next one. (But beware of assuming that any fixed amount of time will be sufficient for a programming assignment.)

The above schedule adds up to 20 hrs per week. Some students have reported spending less time, and some have reported spending quite a bit more.

Instructor

The course has an instructor, who has overall responsibility for all students. The instructor is a full-time member of the FSU faculty. The instructor has ultimate responsibility and authority for the course. He/she is the content expert and arbiter in the development of the course materials. The instructor establishes the culture of her course. He/she also assures that course content and materials reflect respective industry standards, and assures, on behalf of the students, that grading is consistent and fair. The instructor normally takes a direct hand in grading examinations.

The Teaching Assistant

Depending on the level of enrollment, there may also be a teaching assistant or grader (TA). The TA supports the instructor. Duties assigned to a TA typically include grading assignments, helping with the grading of examinations, helping the instructor with recitation meetings, taking attendance in lectures, and keeping office hours to answer questions and provide help to students.

The website for this course is http://www.cs.fsu.edu/~baker/cop4610.S05. This is maintained directly by the instructor for this course, in the Department of Computer Science. To get into the detailed material you will need to enter a userid and password that will be This is not the same as your CS userid and password, mentioned above. It will be provided by the instructor, in class. If you have trouble with this COP 4610 Web userid and password, contact the instructor. You should explore the course website, and become adept at navigating among the different sections as soon as possible.

You will need a CS Department computer account for this course. This allows you to send and receive e-mail at a cs.fsu.edu address, and to log in using ssh to the programming servers used for this course. If you are registered for this course and do not already have a CS account, you can obtain this login on line, by following the instructions at http://www.cs.fsu.edu/sysinfo/newstudent.html#cs".

The assignments for this course must be able to compile and run correctly in one or both of the following two programming environments:

• A collection of Sun Microsystems machines running the Solaris Unix (at the time of this writing, SunOS 5.9) operating system for the SPARC instruction set architecture. This pool of machines has a series of hostnames program1.cs.fsu.edu, program2.cs.fsu.edu, program3.cs.fsu.edu, etc., all accessible under the alias program.cs.fsu.edu. That is, if you log into program.cs.fsu.edu you will be randomly connected to on of the machines in this pool.

• An analogous collection of machines running the Red Hat Linux (at the time of this writing Fedora Core 2) operating system for the Intel Pentium instruction set architecture. instruction set architecture. This pool of machines has a series of hostnames linprog1.cs.fsu.edu, linprog2.cs.fsu.edu, linprog3.cs.fsu.edu, etc., all accessible under the alias linprog.cs.fsu.edu. These are dual-CPU machines, and so will behave much differently from a single-CPU machine on concurrent programs.

No matter which of the above systems you log into, you will be able to access your home directory, which contains all of your files. That is because your home directory is stored on a network fileserver, which serves all of the above machines, as well as most of the other machines in the CS teaching labs.

The above machines cannot receive or send e-mail, or access the fileserver that contains your CS homepage. They are just for coding, testing, and debugging programs.

Those are the only machines in the CS Department you are allowed to use for testing programs for this course. If you choose to read your e-mail using your cs.fsu.edu address, you can read it on shell.cs.fsu.edu, or quake.cs.fsu.edu. If you choose to maintain a web page as cs.fsu.edu you will log into www.cs.fsu.edu to maintain your web pages.

Since some of the system calls you will be making, and the network traffic you may be generating, can cause denial of service to other users of the system, you are never to test programs for this course on those e-mail and web server machines. If you do, and your program behaves (even accidentally) in a way that denies service to other users, your computer usage privileges may be suspended, which in turn may case you to miss deadlines for assignments and cause your grades to suffer. This is serious. The kinds of programs you will write for this course, if they have bugs in them, can easily cause a system to hang or crash. That is why the department provides pools of computers for student programming, to minimize the risk of one student locking out everyone.

If you think your program or that of another student has caused one of the Program or Linprog pools to hang: First, if it is your own program that has run amok try to kill your runaway processes using the kill shell command (will be explained further in class and notes). Then, if that does not work, or the problem is with another person's program, or you simply cannot connect to the machine, please notify the System Support Group of the problem so that they can perform a reboot operation.

For questions and assistance related to the CS Department computing facilities, including new account and password problems, and reporting any malfunction of the computers, printers, or network managed by the department, contact the CS Systems Support Group, which is located in room 120 MCH. If the system is working well enough to use the Web, use the Helpdesk on-line problem reporting service. Otherwise, you can call the system group at 644-4019 or 644-0516.

Please do not ask the Systems Support Group for help doing the assignments for this course. That is not their job, and they will not be familiar with the specifics of the assignments. Questions related to the content and assignments for this course should only be addressed the instructor or TA for the course.

Of course, you may also use computers outside the CS Department to write and debug your software. If you have a Linux or Solaris workstation, that may work fine --- if you have the same or nearly the same version of Solaris or Linux as is running on the Program and Linprog cluster. However, if you have a Microsoft Windows or Apple Macintosh workstation the programming environment there is not likely to be sufficiently compatible.

In any case, before you turn in an assignment you are responsible for checking that it will run correctly on the system or systems specified for that assignment. Students who chose to pursue this option in previous terms discovered that it took them longer to iron out system differences than they expected. In some cases they ended up turning in programs that earned failing grades because they would not compile or would not run on the system where they were tested by the grader. Making sure the assignment is debugged on the right system is the student's responsibility. "It compiled and ran fine on my system!" is not an acceptable excuse.

The Course Syllabus summarizes what students should expect from the course and what the instructors will expect of students in the course. Important topics covered include:

• Instructor Contact Information
• Class Meetings
• Catalog Description
• Prerequisites
• Objectives
• Topics
• Materials
• Assignments
• Grading
• Academic Honor Code
• Accommodation for Disabilities
• Communication

As stated in the Syllabus, you are required to read the FSU Academic Honor Code and abide by it. The Academic Honor Code not only puts you on your honor not to cheat. It requires that you report any cheating that you observe. The purpose of this section of the Study Guide is to clarify what is allowed and what is not allowed with respect to the kind of cheating that gives us the most trouble in CS courses, i.e., plagiarism.

Most students are honest, have a well developed ethical sense, and don't need to be given such detailed instructions on what is allowed and what is not. However, because of University policy and a few past experience with students who tried to excuse cheating by complaining that the rules were not stated clearly enough, it has become necessary to draw sharper lines and go into more detail.

By turning in work for a grade in this course you are representing it as being entirely your own individual work. Unless otherwise specified in writing, all homework (including all programming assignments) is expected to be individual work. If any assignment permits teamwork, it will be explicitly stated so in the assignment, and then the work is required to be only the work of the people on the team.

You may well ask "What does `individual work' mean? Shouldn't I make sensible use of references and prior art?". When a person has a question or a problem it is normal to search publications (including the web) for information, ideas, and sometimes even code. However, there are intellectual property laws and academic ethics that restrict what you can do with the work of other people, and some still stronger restrictions on what you can do for programming assignments for this course. The following paragraphs are intended to explain these restrictions. However, these are distinctions that can sometimes appear to be fuzzy. If, after reading this section, you are still in doubt about whether something you are considering doing would be a violation of intellectual property law, academic standards, or the rules of the course, you should either refrain from doing it, or consult the instructor for a ruling. Likewise, if you are unsure whether something you have observed is allowed, please do not hesitate to consult the instructor.

It is important for all citizens, especially future writers and software development professionals, to understand the basics of intellectual property law. Computer software is subject to both copyright and patent law. Copyright law protects the representation of a written work, whether it be a photograph, drawing, diagram, text, or computer code. Copyright law says that all such works start out as owned by the original author and cannot be copied legally without permission of the owner. If you have permission to copy, you generally required to give credit to the copyright holder and a note saying that the work is reproduced with her/his permission. There is an exception for copying small amounts of text without permission, if you identify such quotations and give credit to the author, under a vaguely defined principle called "fair use". Patent law protects the ideas behind a work. It restricts what you can do with ideas you get from other people. If an idea is patented, you cannot use it at all without a license.

Unfortunately, simple statements about law -- like the ones above -- always turn out to be oversimplifications. That is the nature of the legal system. The laws are complex and are continually being modified by the actions of legislatures and courts. Every lawyer I've ever asked for legal advice has ended by saying he cannot predict the outcome if a case comes to trial, since the ultimate decisions are in the hands of the specific judge or jury. So, what should a person do? Do your best to gradually become better informed of the law. For example, you could read one or more of several tutorial's on the Web. FSU's ODDL has placed links to some such tutorials at http://online.fsu.edu/learningresources/academics.html#copy. Then, you should exercise conservative judgment. If you are in doubt about whether what you are about to do would be a violation of intellectual property law, you should either refrain from doing it, or consult a lawyer to get clarification.

Scholarly ethics start with the law, and go further. Academic ethics require that if you use information or ideas obtained from the work of another person you must at least give proper credit to the original author, identifying what you have used, where you obtained it, and who is the person to whom credit is due. Failure to give proper credit or properly indicate uses of someone else's work is plagiarism, which is a violation off the FSU Academic Honor Code. Giving credit means citing the source of the information in the body of the paper (or program) at the point where it is used, and then including a full citation for the source in a list of references at the end of the paper (or program). Further, if any material -- and this includes diagrams and computer code, as well as text -- is used verbatim, it must be clearly identified as quoted text and include a citation of the original source. You must use quote-marks around each section of quoted text in a paper (and special delimiting comments for code), with a number or abbreviation for the in-line citation, referring to an entry in a list of the full citations at the end of the document. For a more detailed explanation of plagiarism, I suggest you read FSU Political Science Professor Dr. Paul Hensel's web page on plagiarism and proper citation practices http://garnet.acns.fsu.edu/~phensel/citation.html.

In the context of this course --- because programming assignments are used to assess what you have learned, and because even a few lines of code may represent a great deal of creative thought --- you are held to a higher standard for originality and independence of programming assignments than you may have found for the work in some other courses.

• For programming assignments in this course, you are required to design and write your own solutions. You are not allowed to show your code to another person or to read the code of another person, other than one of the instructors for this course.

• You may not put more than two (2) lines of code related to a solution to a programming assignment in any message to a person other than the instructor or TA for this course.

• You are responsible for taking steps to protect your code, including setting the permission bits on the directory containing your code to make unreadable to anyone except yourself, not leaving a workstation where you are logged in unattended (someone might step up and read your code or print out a copy), and not leaving printouts of your code in the printer or a public wastebasket. This also means you cannot send all or part of your solution to an assignment to another student by e-mail, chat-room, or bulletin-board. If another student leans over your workstation to read what you are doing, tell them to back off, and contact the lab monitor if they persist in trying to read what you are doing.

• The only source code written by another person that you may reuse in a program that you turn in for grade are the following:

  1. Code provided by the instructor of this course for this term in a public forum, provided you clearly identify the code that is reused and where it came from. (Code from other courses, or prior offerings of this course may not be used.)

  2. Code you found in a textbook used in a course you have taken, provided you clearly identify the code as reused and include a citation of the textbook in your comments.

  3. Code you found published on the Internet, provided you mark it clearly as reused, include the URL in a comment, and the web site where you found it has a clear statement giving permission for anyone to reuse the code.

• If you reuse source code of type (2) above, limit yourself to comparatively short blocks of quoted code. Excessively long quotations from a textbook may violate the "fair use" provision of the copyright law, and in any case are considered poor academic practice. The same is true of excessively long quotations of text in a research paper. Moreover, the purpose of the assignments assignments in this course is for you to practice your own writing and programming skills. Therefore, you will not get credit for a research paper that relies on an excessive amount of quoted text, or a program that relies on an excessive amount of quoted code.

• The only libraries you may link in with programs you turn in are standard libraries defined by the C/C++ language standards and the POSIX/X-Open Unix standards, that are available on the systems provided by the CS Department for you to do your assignments.

Failure to follow these rules will be considered a violation of the Academic Honor Code. The first detected violation will result in a grade of "F" or zero for the work in question. A second detected violation will result in a grade of "F" for the course, with no possibility of taking the course for grade forgiveness.

The instructor may use the services of turnitin.com or other electronic automated techniques to assist in enforcing these rules.

Objectives:The objectives of the research paper in this course are for you to improve your skills in writing and digging out information, and to gain a deeper understanding of one aspect of operating systems.

When you have reached the end of the course you should have a good enough grasp of the principles and terminology of operating systems to be able to read and understand most of the literature on the subject. However, if you continue to work with computers, you will need to learn more about operating systems. You should be able to teach yourself what else you need by reading. This exercise is intended to push you over that threshhold, between formal education and self teaching.

A secondary purpose of the assignment is to exercise and test your skill at technical writing, on a topic in Computer Science. One of the objectives of the FSU undergraduate CS curriculum is that all students should be able to write a technical report on a topic in CS. All FSU undergraduate students are required to take courses in writing, but the courses that satisfy this requirement generally do not necessarily cover technical writing (as compared to poetry, short stories, and other forms of creative or informal writing), and certainly do not require students to write on topics in Computer Science. This course is one in which that is done.

Organization & Format: The form of the paper should follow the typical form of a Computer Science research or technical report. In particular, it should include the following components:

• Title page, with title, author, course, and date
• Abstract page, summarizing the content of the report. [one paragraph]
• Introduction, summarizing the purpose, content, and organization of the paper. [for this course, 1/2 page to a whole page]
• Body, comprising several sections, each several pages long. [for this course, two to five sections, each a few pages long]
• Conclusion, summarizing the content of the paper and emphasizing what you think are the main insights or conclusions of your research. [for this course, between 1/2 a page and a whole page]
• Bibliography, a numbered list of complete citations of the sources from which you obtained the information in the paper (there should be at least one citation within the introduction or body for each of these references). [for this course, at least 4 references]

The ranges of pages shown in square brackets above are suggested lower and upper bounds based on a letter-sized paper (8.5" x 11") with double spacing and 10-12 point type.

Grading Criteria: The paper will be will be assessed subjectively, giving approximately equal weight to the quality of the writing and the quality of the research. In particular, the following factors will be considered:

1. Effectiveness in focusing on the assigned question.
2. Accuracy and comprehensibility of your summary of what you found.
3. Completeness and relevance of references.
4. Thoroughness of research, in finding information relevant to the question.
5. Evidence of analysis, and reflection on the information you found.
6. Understanding, as demonstrated by the ability to correctly express and discuss the concepts in your own words.
7. Clarity of writing.
8. Correct grammar, word choice, spelling, and punctuation.

Submission: You are required to submit your paper in both hard copy (paper) and electronic format. The electronic copy must be in Microsoft Word (.doc), Rich Text (.rtf), PDF (.pdf), PostScript (.ps), or HTML (.htm or .html) format. It should be sent via e-mail to the instructor.

As mentioned in the Assignments section of the Syllabus, there will be several individual programming assignments. The Grading section of the Syllabus tells how the programming assignment grades will be weighted in the computation of the term grade, and the Course Calendar gives the deadlines for all the assignments, along with links to details on each assignment. This section of the Study Guide provides other information and advice regarding those assignments.

• Submitting Assignments provides an overview of how to submit programming assignments, and precautions to take to avoid mishaps.

• How to Work on Programming Assignments gives some work rules and practical advice on how to approach programming assignments.

• Grading Criteria for Programming Assignments explains what we will be looking for when we grade the programming assignments you submit.

• Lateness and Multiple Submissions explains the range of possible consequences of failing to turn in an assignment on its due date, or turning in multiple versions.

• Programming Environment provides information on the computers and operating systems you will use to do the programming assignments.

Programs grades will be assigned according to the following general guidelines:

[0-58]

program not turned in, appears copied, or too incomplete to determine whether principles behind the assignment were understood

[59-68]

program turned in and indicates some understanding of principles behind assignment, but does not work correctly on public test data/cases supplied by the instructor

[69-78]

program works correctly on public test data/cases, is based on correct algorithms, and shows understanding of most of the principles behind the assignment

[79-88]

program works correctly on public test data and also on other data that may be used by the instructor in grading, and indicates understanding of all the principles behind the assignment

[89-100]

program is correct and is also well written, in an economical clear style. (This includes use of efficient algorithms and data structures, and adequate documentation explaining the data structures used and the effect of each subprogram in terms of its parameters and any global variables it uses.)

Within these bands, the grade will depend on matters such as style and documentation. Programs that go beyond the minimum requirements in some respect may occasionally be forgiven a few errors without lowering of the grade, but students are cautioned against writing overly ambitious programs, since this grading scheme is harsh on non-working programs.

In other words: Most of the grade will be determined by how your code performs on tests. The tests will include both normal use cases and cases of detectable error conditions. They will not only test that the code works correctly under simple normal usage conditions, but they will attempt to stress your implementation. Solutions that work correctly on normal use cases will be eligible for a grade of "C". For grades in the range "B" through "A", a higher standard will be applied. Most detectable error conditions should be detected and handled correctly. (Correctness here means following the specifications in the assignment, or if nothing is specified in the assignment, exercising sound judgement as to what would be most useful, least surprising, and least harmful). The implementation should not be inefficient, either in terms of the amount of execution time it takes, or the amount of object code. (Here, we only interested in big differences in execution time and object code size.)

More specific guidelines may be provided for individual assignments. In some cases, there may be optional parts that must be completed to earn a higher grade.

Programming assignments must be submitted electronically. Each assignment will specify any details about how it is to be turned in that are specific to that assignment. It will refer to this section and the Assignments section of the Study Guide for instructions that may apply to more than one assignment. The details in the specific assignment always take precedence over anything that is stated here.

If an assignment calls for you to use a shell script to submit your work, take care of the following:

• The shell script must be executed on the one of the CS Department servers that is specified for submitting that assignment, and which has support for sending e-mail. Normally, this would be shell.cs.fsu.edu, or quake.cs.fsu.edu.

• The shell script must be executed in the context of the directory where you have the version of the source code you want to submit. It will pick up the files that are expected for the assignment, by name, from your current working directory. Ordinarily, you will have a working directory for each assignment, and execute the submit-script in the context of that working directory.

• If the submit-script fails, check that you have followed the rules above, i.e. that you are on the right machine and have all the required files in your current working directory.

• If the submit-script seems to have succeeded, wait a while and check your e-mail for confirmation that your submission has been received. If the e-mail reports any problems, correct the problems and resubmit. If the e-mail indicates there was a problem with your submission but you don't understand the nature of the problem, ask the instructor or TA for this course.

• See the note about Lateness and Multiple Submissions.

Make your Own Backups: We will try to arrange for the submission mechanism to provide a positive confirmation of receipt. However, students are responsible for retaining electronic back-up copies of all work that is turned in, in case network or equipment failure causes loss of the copy that was turned in. Regardless of how an assignment is submitted, before you submit it you should always save a copy of your work to the hard drive of your personal computer or to a removable disk (Zip or floppy). You will then have a backup copy of your work should your assignment be lost or scrambled during the electronic submission process.

File Naming Conventions: Regardless of how an assignment is submitted, your instructor will specify a file naming convention that will allow your submitted work to be easily identified, among different assignments that you and other students submit for the course. It is essential that you follow the file naming convention for the assignment, or else your work may not be graded. For example, if the assignment says you are to name a file "prog1.c" and you name it "program1.c" it may not be graded.

File Formats: For program files, you are required to submit your code in a form that can be compiled under the Unix operating system, which uses a single character (^J) to indicate an end of line. The code should not contain any tabs or other nonprintable (formatting) characters. Take care that you do not use a Windows/DOS editor to edit program files. Windows/DOS uses two characters (^M^J) to indicate an end of line. The extra character (^M) will prevent your program from compiling under Unix. Also take care not to process code with a word processing editor or e-mail tool that inserts blanks, tabs, or other "whitespace" characters at the ends of lines. Likewise, do not try to send source code in e-mail using a Windows-based mail agent; they are known to insert line breaks in long lines. In C-language macro definitions, adding extra whitespace at the end of a line can cause compilation errors. Likewise, breaking a line can cause syntax errors. The instructor has no recent analogous experience with Macintosh systems, but common sense dictates that there are likely to be similar pitfalls. To avoid such problems, you should do all of your editing of program code for this course on a Unix/Linux system, using either the emacs or vi editor. You may upload and download C/C++ source files to your workstation for backup, but you should probably not try to modify them there unless you are very savy about avoiding the above kinds of problems.

The policies on late programming assignments and effect of programming grades on the course grade are explained in the Grading section of the Syllabus.

If you submit more than one solution to an assignment, only one solution will be graded. If all your submissions are on time, the last submission received will be graded.

If one or more of your submissions is late, there is no guarantee which version will be graded. Ordinarily, it will be whatever version was last turned in up to the time the grader gathered the submissions and began testing them. Do not expect the grader to pick the "best" version. For example, suppose you turn in Version A of your solution before the deadline, then discover that it has defects, try to fix the defects, and turn in Version B after the deadline. It is possible that Version B is graded and gets a higher grade, but then the grade is reduced for lateness, possibly to a lower grade than you think you would have obtained for Version A. If this occurs, you cannot expect the grader to go back and redo the grading using Version A. (You may ask, politely, but if the answer is "no", you must accept that.)

1. Do your own work on all graded assignments, as explained in the Study Guide section on The Honor Code & Plagiarism.

2. Get the help you need from your instructors for this course, in an approved form. This means:

   • It is perfectly OK, and expected, to seek help from the course instructor or TA, in person or via e-mail. Always bring an up-to-date printout of your source code (or be prepared to log in and let the instructor view your code on a window of the instructor's workstation) when seeking help in person. When using e-mail, put the code you want to discuss in the body of your e-mail and embed questions inside the code beginning with comments, e.g.

     /* Q: (insert question here)
     */

     Remember, this is appropriate in e-mail to instructor(s) but not in any other discussion forum. Understand that the instructors time is limited, and must be shared among all the students in the class. This is a special problem near the deadline for an assignment.

   • It is good to bring up questions in class (lecture or recitation), and it is encouraged that you participate in these discussions. Just be careful not to disclose enough of your solution to an assignment for another student to copy.

3. Start programming assignments early, and allow for them to take much longer than your worst-case initial estimate. You cannot rely on your estimate of how much time it will take you to complete and assignment, or how long it takes another student in the class. No one -- neither you nor the instructor -- can predict accurately how long it will take you to complete a programming assignment. The following two facts have been published in software engineering research:

   • Even experienced professional software developers frequently underestimate the work needed to complete a project by a factor of two or more.
   • Even experienced professional software developers with the same amount of experience have been observed to differ by a factor of up to six (6) in the amount of time it takes them to completed a project.

   If you find you are spending a lot of time without seeming to make progress, don't just keep banging your head against a wall. Take a mental step back and try to figure out what you are doing wrong. Seek help from the instructor.

   Get started on assignments early enough that if you run into any difficulties that require asking questions there is enough time for the instructor or TA to get back to you. The instructor or TA will check e-mail periodically, especially during office hours, but they will not be on line all the time. An e-mail sent in the evening may not be seen until the following day, and an e-mail sent on a weekend may not be seen until the following Monday. Moreover, if several students wait until the last minute to ask questions, it may not be possible to respond to all of them in a timely fashion.

   Get started on assignments early enough that you do not run into congestion on the programming servers. Those machines can slow down considerably if everyone tries to use them at once, especially if a few students have bugs --- like infinite loops or recursive fork() calls --- that are chewing up all the system resources or have caused the one or more of the systems to crash.

4. Keep your files organized.

   • Create a directory for this course (e.g."cop4610") and do all work for this class inside that directory. Make sure this directory has Unix access mode "700". (In the parent directory of cop4610, enter the command "chmod 700 cop4610".)

   • Create a separate subdirectory, and work within that subdirectory, for each programming assignment.

   • Save your source from prior assignments, but not the object code. This will save your disk space allocation. (An instance where time is cheaper than space.) Hitting your disk quota in late just before an assignment is due can ruin your work schedule.

   • Periodically make a backup copy (just one) of your source code files, in a subdirectory of the place where you normally work, or on a different system. Keeping the backup copies in a separate directory or another machine will protect you against accidental removal.

   • Do not keep multiple copies of different versions of attempts at solutions to programming assignments. You will get confused, and test, turn in, or delete the wrong one. If you want to be able to go back to earlier versions, consider learning to use SCCS or RCS to keep a read-only history of all your changes for each file. (You can read the man-pages on for rcs and the basic commands ci and co, which are used the check in and check out files for editing.)

5. Keep your distribution files up to date. For some assignments, there will be some source code that is provided for you by the instructor. In an ideal world, this code would be static. In reality, students may discover defects in this code, and report them to the instructor. The instructor will then update the provided code and notify all students by e-mail of the change. You will be responsible for using the new code. We hope this will not happen often.

6. Stick to the programming interfaces defined in the assignment. Some assignments in this course will consist of writing code modules, which will be tested by linking them with test programs designed by the instructor. The interface to such modules will generally be defined in a C header (.h) file. There will be instructions not to modify this header file, or comments indicating limitations on what may be modified. Adhere to these constraints, or risk your module failing to compile or failing to run correctly when it is tested for grading.

7. Learning to write portable code is an objective of this course. If you use an library files, they must be standard ones provided by the Unix operating systems on the Linprog and Program clusters. For each assignment it will be specified whether the code must run on just Linprog, just Program, or both. Generally, stick to the standard ANSI C, X-Open, or POSIX libraries, which are supported on all Unix systems. When compiling your code, use the gcc compiler with the "-ansi -Wall -pedantic" options. Pay attention to correct use of feature-test macro definitions (e.g. #define _XOPEN_SOURCE) to enforce standard-compliant versions of header files are used.

8. See the directions given in the section Programming Environment of the Study Guide, about cross development. If you develop code on a system other than then one on which the assignment says programs will be tested, it is your responsibility to verify that it compiles and runs correctly in the test environment, before you turn it in. Remember that "It compiled and ran fine on my system!" is not an acceptable excuse.

9. Design and code for debugging and maintenance. When coding, make good use of built-in debugging techniques, including the assert macro, and use #if DEBUG conditional code and dynamic debugging flags for execution tracing. Design debugging trace code so that it can be safely left in, but disabled, for final delivery. (Dynamic debuggers, such as gdb are of some use, but have inherent limitations for concurrent and asynchronous code such as you will be writing in this course.)

10. Try to approach your programming assignments in a systematic way.

    • Analyze and Understand
      • The assignment in general terms
      • Each detailed requirement
      • The given interfaces and code, if any
      • Required deliverables
    • Design
      • Data and data structures
      • Algorithms
      • Functions to implement operations on data structures, and algorithms
      • Function main(), if not provided
      • Makefile, if not already provided
      • Unit tests for functions
    • Code
      • Datatype and global variable declarations
        • Comment intended uses, users, and important invariants
      • Functions
        • Stub some/all functions initially
        • Comment the intended effect of function. Comment the general idea of how it will accomplish the effect, unless that is obvious.
        • Write functions a few at a time
        • Design in some basic logging facilities, so that you will be able to tell whether the functions are working correctly
        • Debug individual functions with unit tests
        • Integrate after individual functions are known to work
    • Test
      • Write your own unit test for functions (above)
      • Use the tests provided by the instructor
      • Think up your own variations, and harder tests, such as may be used in grading the assignment

As mentioned in the Assignments section of the Syllabus, there will be several quizes, two midterm examinations, and a final examination. This section of the Study Guide provides additional information and advice regarding examinations, along with links to places you can find other relevant information.

• General Advice on Taking Exams offers some general advice on preparing for and taking examinations in this course.

• Sample Examinations provides links to some sample examinations, from earlier offerings of this course.

• The Course Calendar gives the times of all quizes, midterms, and the final examination.

• The policies on examination times and missed examinations for all students are given in the Assignments section of the Syllabus.

• The effects of quizes, midterms, and the final examination on the course grade are explained in the Grading section of the Syllabus.

The following simple rules will help you get a better score on any examination:

• Get plenty of sleep the night before.
• Watch your diet before the exam. Protein promotes wakefulness. Eat an egg or other high protein breakfast (or lunch, as appropriate). Avoid loading up on carbohydrates; they bring on sleep. Avoid excessive caffeine; it can make you jittery, leading to stupid errors on exams.
• Remember to write your name on every page, and turn in all pages of the exam.
• Budget your time.
  • Don't fail to answer some easy questions because you got bogged down on some other questions.
  • If you have trouble with a question, skip on to the next one. Go back late to the ones that cause you trouble.
• Read each question carefully and completely, to make sure you understand it.

Easy Questions

Each examination will contain a mix of questions of different degrees of difficulty. A large fraction of each exam will be intended to be "easy". The intent is that a person who earns all the easy points should be able to earn a grade of C- or better. There will be some questions that require deeper knowledge, either to get full credit on the question, or perhaps to answer the question at all. The intent is that for a person to earn a high grade, such as A or B, the person must be able to earn some of the harder points.

A good place to begin studying for the examination is to make sure you will get all the easy questions correct. A question is easy if one only needs a superficial knowledge of the relevant topics to get the question right, or to get substantial partial credit on the question. A question is also easy if it is approximately a repeat of a question on a quiz or examination earlier that term, or a question on a published sample examination from a prior term. Be sure you can define and use the Terms listed at the end of each of the chapters you have been assigned to study. Questions about the meanings and usage of those terms are considered easy. Also be sure you are able to answer the Review Questions at the ends of those chapters. These also will be considered easy questions. Be sure you can answer all the questions on both previous examinations, including anticipated variations on those questions. That is, don't just memorize answers, but make sure you really understand the facts and reasoning behind the question. If the final examination revisits any of these topics via variations on the old questions, those will be considered to be easy questions.

Harder Questions

Among the harder questions you should expect more emphasis to be on topics that we covered at most depth in the readings, lectures notes, and assignments. You are more likely to be asked a deep question about a topic that appears in both the lecture notes and the text, and especially likely to be asked a deeper question about a topic that is also covered by a programming assignment or the term paper.

Another Way of Looking at Examinations

The following is another way of looking at how the level of detail and depth of analysis you are expected to be able to provide on the exam relates to how you learned the material:

• Topics covered in homework assignments
  • write, read, explain code
• Topics covered in on-line lecture notes
  • understand concepts
  • answer true/false questions
  • understand & explain examples, including code
  • answer questions embedded in on-line notes
• Topics covered in textbook readings
  • understand concepts
  • understand & use terms correctly
  • match terms with definitions
  • define terms
  • answer true/false questions
  • answer questions like the review questions
  • answer questions like the textbook exercises
• Topics covered in term paper
  • write a short-essay answer

The following examinations from previous terms are provided for your benefit in preparation for the examinations this term:

• Midterm Examination #1 from Spring 2002, without answers
• Midterm Examination #1 from Spring 2002, with answers
• Midterm Examination #2 from Spring 2002, without answers
• Midterm Examination #2 from Spring 2002, with answers

Additional example examinations may be added to the list above, later in the term.

Take care not to misunderstand the intent of these sample examinations. On the one hand, do not limit your studying to these exam questions, or to the topics that are covered on these exams. You can expect that your examinations will certainly include some new questions and cover some additional topics. On the other hand, do not ignore these questions. It is quite likely that some of the questions on these exams or -- more likely -- variations on the questions on these exams will show up as "easy" questions along with the new questions on your exam.

The Course Calendar summarizes the important dates for the term, including examination and assignment due dates for all students in the course, and class meeting times. It will be updated, as necessary, throughout the term.