CMPUT 498:
Concurrency, Performance, (Pride), and Architectures in Software Systems
Department of Computing Science
January 2004

Assignment #2: Barrier Synchronization in Java
Due Date: Wednesday, April 7, 2004
(Penalty-free extension of 1 week)
Email tar file to instructor before 9 P.M. on due date.
This is an individual assignment. Do NOT work in groups.

Overview:

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.

Standard Comment About Design Decisions

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.

Detailed Specifications:

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.

Testing:

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:

  1. Does the barrier synchronization work for variable numbers of threads?
  2. Can the barrier synchronization detect a simple, common error such as when a thread skips one barrier call-site and blocks on the next (wrong) barrier call-site?

Other Implementation Details:

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

What to hand in:

All elements are to be handed in by email to your instructor.

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.

  1. A README file (ASCII text is fine) for your assignment with: (1) your name, (2) student number, (3) Unix id, (4) lecture section, (5) instructor's name, (6) lab section, and (7) assignment name clearly labelled. Marks will be deducted if any of these items are missing. The README file must also include a short description of your program, as well as a description of the relevant commands to build (e.g. make all) and how to execute your programs including command line parameters.
  2. A report in HTML file format, in a file called report.html, describing the design, implementation, and testing of your assignment. The report should contain no more than 1000 words. (If lynx -dump -force_html report.html | wc -w is greater than 1100 (i.e., 1000 + a small margin; 1101 is too many words), then marks will be deducted.) You do not need to repeat any information contained in this assignment description. I recommend you spend 25% of your report on an overview of your assignment, 25% on your design and implementation, and 50% on how you tested your program, and some concluding remarks. Note the emphasis on testing your program.
  3. Your source code file(s).
  4. Your Makefile.

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

Marking:

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.

Hints:

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.