Goals

There are two main goals for this project:

• To familiarize you with the dlxos system - how it works, how to use it, and how to compile code for it.
• To allow dlxos to support monitor-like synchronization by implementing additional thread synchronization primitives - locks and condition variables - using only the semaphores already provided in the system. The locks & condition variables should use Mesa-style monitor synchronization. Definitions for the locks and condition variables are in synch.c and synch.h.

You may not use busy waiting to implement this assignment; nor may you turn off interrupts. The only synchronization primitives you may use are semaphores. The public interface to these objects is already provided for you in synch.h; you must use this interface without alteration. The only files you'll need to modify are synch.h, synch.c, and process.c (you're probably going to want to create different processes to test your implementation).

We assume that you are already familiar with makefiles and debugging from classes such as CMSC 341. If not, this will be a considerably more difficult project because you will have to learn to use these tools as well.

This project doesn't require a lot of coding, but does require that you understand what's going on inside the operating system. You're encouraged to visit the professor's or TA's office hours to get help if you need it.

IMPORTANT: As with all of the projects this semester, the key to success is starting early. You can always take a break if you finish early, but it's impossible to complete a 20 hour project in the remaining 12 hours before it's due....

Testing

Testing your code is an important part of the assignment. You should run as many tests as necessary to convince your group members (and the TA...) that your code works. This can be done by including several sets of tests in a single executable (selectable by passing arguments to the operating system via the -a option to the simulator) or by having several different versions of the source file. Either way, you should include a README file with your code to explain how you tested it.

The best way to write tests is to create several processes in the operating system and see whether they synchronize properly. Try creating 20 processes and using several sets of locks and condition variables and see if everything works correctly.

What to hand in

As with other projects, you'll need to hand in your design documentation and your code. The design documentation is due a week after the project is assigned, and the code is due on the final due date. The due dates are listed at the top of this assignment.

Design documentation

Your design documentation should describe the design of your project. This includes the data structures you're going to use, as well as the high-level pseudo-code for each high-level function. For this assignment, the high-level functions are pretty much the only functions you're going to need. For later assignments, though, you may have lower-level functions that aren't part of the "public" interface. We suggest that you document major functions that aren't visible - it makes design simpler - but you don't have to document every single function you're going to implement. A sample design document is available online.

Your design documentation must be handed in online using submit. Each group should hand in a single design document, but make sure that all group member names are on the document. You have a wide range of choices for document format, but your documenation must be in one of these formats. If you choose to use HTML, please make sure that any figures are included using relative path names - all files must be in the same directory.

Project code

Please turn in all of the files you used to build your project: source code, Makefiles, and any other scripts you may have used. In addition, please include a README file to explain anything unusual to the TA - testing procedures, etc. Your code and other associated files should be in a single directory so they'll build properly in the handin directory. As with your design documentation, each project group should hand in a single working project (i.e., only one group member should run submit). If a group hands in multiple designs, the TA will choose randomly among them.

IMPORTANT: don't submit object files or other files generated by the DLX compiler or assembler. Every file in the handin directory that could be generated automatically by the DLX compiler or assembler will result in a 5 point deduction from your project grade.