School of Computer Science & Software Engineering CITS3213 Concurrent Programming Assessed laboratory

This is the assessed laboratory sheet for CITS3213. It contributes 20% of your final mark. You should work on this laboratory in groups of two. One member of each group should submit the group's completed project (names and student numbers of group members, code, tests, and a report) by 11:59 pm 6th June via cssubmit. You are expected to have read and understood the School of Computer Science Policy on Plagiarism. In accordance with this policy, you may discuss with other students the general principles required to understand this project, but the work you submit must be the sole effort of your own group.

Overview

You are required to implement a system for mutual exclusion that accommodates multiple resources, and is decentralized in the sense that clients interact with each other directly instead of via a centralized manager or shared data structures. The following files will help you in the lab.

• The Java source file ResManager.java contains an outline of the code for a class of resource managers. Each client will create an instance of this class, and will use it to request and release resources. Your main task is to complete the code in this class.
• The Java source file ScheduledTester.java contains a tester that allows you to test your ResManager class by specifying particular timings for requests and releases by each client, with any number of clients and resources. You may want to create many copies of this class with different timings.
• The Java source file RandomTester.java contains a tester that allows you to test your ResManager class with randomized timings for requests and releases. You may want to create multiple copies of this class for tests with different numbers of resources and clients, and shorter or longer average times. (Both testers use indentation so that the events for a particular client are easy to see.)
• The text files ScheduledTester.out and RandomTester.out which contain sample output for the above test files, obtained using a (most likely) correct implementation of ResManager.

Requirements

Your ResManager class should meet the following requirements.

1. There are a certain number of clients, numbered 0, 1, ..., n-1, and a certain number of resources, numbered 0, 1, ..., r-1 (with r < k).
2. Each client will need to use one of the resources from time to time, and only one client is allowed to be using each resource at any particular time.
3. When a resource is needed, the client will call the getResource() method on its own instance of the ResManger class.
4. The ResManager class should locate a resource that is not being used by another client, and return the number of that resource. If all resources are busy, getResource() should wait and return the first resource that becomes available. When many clients are waiting for resources, it does not matter which order they are given resources.
5. When the client is done with the resource, it will call the releaseResource() method on its ResManger.
6. Each ResManager should interact directly with the others to locate resources, and wait for them to become available. This interaction should be via methods calls only. No shared data structures are allowed. Waiting should be done via the appropriate Java mechanisms. Busy waiting, or periodic polling are not considered appropriate.
7. Each ResManger should keep track of which client holds which resource, but should only update this information when the ResManager is involved in the resource being allocated to a different client. When a resource is reallocated and a ResManger is not involved, its information will thus be out of date.
8. When a ResManager receives a request from its client, it should contact the ResManager of the holder of each resource, according to its information, to request the resource. If the contacted ResManager no longer holds the resource, it should forward the request on to the holder according to its information. When eventually the resource is located, the original client's ResManager should be informed when the resource becomes available, and the resource should be allocated to that client if no other resource has become available first.
9. When a ResManager obtains a resource, it should cancel its requests for the remaining resources.
10. When a ResManager obtains a resource, the ResManager releasing it should update its information on who holds the resource. Conversely, if a request is canceled, the original requester should update its information. In either case, any ResManager involved in forwarding the request should also update its information.
11. Initially client 0 holds resource 0, and 1 holds 1, and ... and client r-1 holds r-1. The other clients hold no resources, and every ResManager knows this initial allocation.
12. A ResManager which holds no resource and does not request one should not be involved in any communication with other ResManagers, except for the limited period where it forwards requests if it held a resource at some point in the past.

Submission and Assessment

You should submit the Java source code for your ResManager class (ResManager.java), some test classes that demonstrate that your code meets the requirements, and a short report. Make certain that you submit all three.

Your code will marked on how well it meets the specification, as well as its elegance, clarity (how easy it is to read), and how appropriately it uses the concurrency features of Java. This forms 60% of your mark for the project. Code that uses shared data structures, busy waiting or periodic polling is likely to receive a low mark, since this defeats much of the point of the exercise.

Your tests may be either variants of the supplied test classes or your own test code. They should demonstrate that your code meets the requirements, or at least come as close to this as is practical. Each one should include a clear explanation of the specific aspect that it is designed to test. The tests will be marked on their appropriateness, and on how well they test the intended aspects. The tests will contribute 15% to the mark for the project.

The remaining 25% will be based on a brief report (roughly 1-2 pages) that describes:

• The structure of your program and how it works, particularly focusing on the concurrency aspects.
• Any particularly interesting features of your program.
• How well your program works, including any situations or tests for which it doesn't work.
• The steps you followed in building your program, focusing on the problems that you needed to solve in this process.
• A reflection on your experience with this project. Was it too easy or too hard? Too long or too short? Interesting or boring? A good learning experience or mostly pointless? What could have been better?

Getting Help and Forming Groups

Help will be available in the lab sessions. You are also encouraged to make use of https://secure.csse.uwa.edu.au/run/help3213 to discuss issues related to the project with other students and the teaching staff.

Please also use help3213 to find lab partners. Post if you need a partner, check to see who else is looking for a partner, and post to tell people when you have found a partner. (And pause to consider the concurrency issues involved in this project partner system.) I have started a thread "Assessed Lab partner" for this purpose.

May 2008