COSC 374
Operating Systems
Spring 2002

Programming Project #2

Assigned: 19 February, 2002
Design Due: 1:14 P.M., 28 February, 2002
Project Due: 1:14 P.M., 14 March, 2002 (after Spring Break)

Please make sure you've read the general project information page.

Goal

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

Testing

Testing your code is an important part of the assignment. You should run as many tests as necessary to convince yourself and the instructorthat 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. You may wish to use classic synchronization problems such as Dining Philosophers to do your tests.

What to hand in

As with other projects, you'll need to hand in your design documentation and your code, both of which must be handed in using the submission system described on the main projects page.

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.

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 me - testing procedures, etc. Your code and other associated files should be in a single directory so they'll build properly.

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.

Grading

I will likely test your code by inserting processes that make calls to your locks and condition variables. Thus, you must use the function call names already included in synch.h.
 

Last updated 18 February 2002, by Clay Shields, from a page by Ethan Miller (elm@cs.ucsc.edu)