You are asked to implement and (more importantly) test the concept of a barrier synchronization, using Java. Your assignment should work on the Linux-based workstations in CSC 219.
Although many details about this assignment are given in this description, there are many other design decisions that are left for you to make. In those cases, you should make reasonable design decisions (e.g., that do not contradict what we have said and do not significantly change the purpose of the assignment), document them in your source code, and discuss them in your report. Of course, you may ask questions about this assignment (for example, in the newsgroup) and we may choose to provide more information or provide some clarification. However, the basic requirements of this assignment will not change. |
You should write a new Java class, called C498Barrier. Note that the Doug Lea textbook has an implementation of a barrier in Chapter 4.4.3. It is OK to use that code from the textbook as the emphasis for this assignment is mostly on the testing (and extension) of the barrier implementation. If implemented properly, the basic C498Barrier can be used as follows:
C498Barrier aBarrier = new C498Barrier( numThreads ); ...snip... aBarrier.barrier(); |
The remainder of the assignment has to do with testing and extending the C498Barrier to addressing the issues discussed below in Testing. Note the Standard Comment on Design Decisions.
At a minimum, your barrier should work with the matrix multiplication example discussed in class. In fact, you must implement a variation of the matrix multiplication application that computes: A X B = C followed by B X C = A. The initial contents of the matrices do not matter, but you should convince yourself (and myself) that the correct computation is being performed.
Additional aspects that you should write test programs to test include:
You must write a Makefile for your program. You must use the javac compiler. When someone types make, your Makefile must build all the relevant classes for your assignment, including the test program(s). When someone types make test, your Makefile must run a test to demonstrate the desired functionality. When someone types make clean, your Makefile must remove all executables (if any), all .class files (if any), and all core files (if any).
All of the following must be packaged into a tar file with the name submit.tar. Information about tar is available from the manual page (see man tar). For example, tar cvf submit.tar Makefile main.c my.h is an archetypal command; be very, very careful of the tar cvf submit.tar part. Before you submit, make sure your tar file works from within a fresh directory.
Also, make sure that your program does not produce any debugging or extraneous output. Only the requested output should be generated.
Note: All files in your submission must contain the identification information labelled (1) to (7) in point 1 above (e.g., as a Java or Makefile comment).
The assignment is worth 15% of your final mark in the course. This is an individual assignment. Do not work in groups.
The assignment itself will be marked as follows: 20% for your report (clarity, technical accuracy, completeness, thoroughness of the testing, etc.), 40% for the correctness of the program when we test it using CSC 219, using javac, and 40% for the quality of the implementation (design, modularity, good software engineering, coding style, useful and appropriate comments, etc.) and thoroughness of the testing.
Your source code, as submitted, must compile and run (using the submitted Makefile) on the CSC 219 workstations using javac.
All that you have learned about good technical communication (e.g., for your report) will apply. All that you have learned about good programming style and comments in your code will apply. Having correct code is important, but good style, design, and documentation are also important. We cannot provide an exhaustive list of what we will look for, but an incomplete list includes: a comment for each source code file, a comment for each procedure/function, a comment for each significant (global or local) variable, good choice of names/identifiers, proper modularity (e.g., do NOT put all/most of the code in main()) etc.
Further hints may be given later on in the newsgroup, if warranted. Be sure to read the newsgroup on a regular basis.
Cleaning up runaway processes is good etiquette when using a shared computer. For this course, it is a necessity. Make sure you know how to use the ps and kill commands.