C C S D assg

Objective:

This assignment has been designed for students to apply appropriate concurrent program design methods in designing and implementing a concurrent program from a program specification.

Marking Criteria

The criteria used to evaluate the assignment are as follows:

• Overall program structure – structure diagram
• Appropriateness of coding techniques used to implement design
• Appropriateness of the Java concurrent programming facilities used
• Program runs appropriately
• Appropriateness of concurrent program design - FSP
• Appropriateness of Class Diagram
• Usefulness of instructions for compiling and running the program including comment lines in source codes.
• Presentation of the LTS diagrams and LTS traces.
• Presentation of the source code listings – except UI-related codes
• Reporting of appropriate tests of program execution
• Depth of discussion – listing of section(s) that did not meet requirements and/or code extracts of sections that met requirements.
• Critical Appraisal

Performance Criteria

1. A demonstration of your work to the lecturer. Marks will be allocated on the basis of your ability to deliver a coherent, clear and well-prepared verbal presentation of your system. To achieve a mark of:

o Fail: Not able to articulate and explain basic functionality of system

o Pass: Your delivery must be clear, but may suffer from a lack of organisation or preparation.

o Credit (2^nd Lower): As above, plus your presentation is clear, well organised and prepared.

o Credit (2^nd Upper): as above, plus be able to clearly answer questions from your lecturer about your system. Your examples cover the majority of the functionality of the system, and are well chosen to do so.

o First Class: as above, plus the presentation must have an extra spark that makes it stand out from the other presentations. This mark is reserved for presentations that are of an excellent standard.

2. Assessment of functionality. This will be assessed by your tutor experimenting with your electronic submission. To achieve a mark of:

o Fail: Your system cannot compile with the command javac *.java.

o Pass: The system works properly having met basic requirements. .

o Credit (2^nd Lower): As above, plus the system provided meets all expected functionality.

o Credit (2^nd Upper): As above, plus the system is free from deadlock

o First Class: As above, plus the system must have an extra spark that makes it stand out from other systems. This mark is reserved for systems that have outstanding functionality, and is free from data corruption and deadlock.

3. Report on Correctness. This report must provide an argument of how you know that your system behaves correctly. To receive a mark of:

o Fail: Your report cannot be easily read by your lecturer and has many missing parts.

o Pass: Your report must be easily read, informally outline the particular concurrency issues that your system faces and meet satisfactory documentation requirements (seem marking criteria above).

o Credit (2^nd Lower): As above, plus you must provide one of a test report or a theoretical argument (e.g. verified FSP descriptions of your system) which shows that your system is free from data corruption and deadlock.

o Credit (2^nd Upper): As above, plus you must provide LTS traces in additional to LTS diagrams that shows that your system is free from data corruption and deadlock.

o First Class: As above, plus the report must be among the best in the class, and must stand out from the other reports in your class.

MARKING SCHEME

Criteria	Marks (10 marks for each criteria below)
	Excellent (10/9)		Good (8/7)	Average (6/5)		Poor (4/3)		Very Poor (2/1/0)
1. Overall program structure – structure diagram
2. Appropriateness of coding techniques used to implement design
3. Appropriateness of the Java concurrent programming facilities used
4. Program runs appropriately
5. Appropriateness of concurrent program design - FSP - Hairdresser
6. Appropriateness of concurrent program design – FSP - Customer
7. Appropriateness of Class Diagram
SUB-TOTAL (T1)
Criteria	Marks (5 marks for each criteria below)
	Excellent (5)	Good (4)			Average (3)		Poor (2)		Very Poor (1/0)
8. Usefulness of instructions for compiling and running the program including comment lines in source codes.
9. Presentation of the LTS diagrams and LTS traces.
10. Presentation of the source code listings – except UI-related codes
11. Reporting of appropriate tests of program execution
12. Depth of discussion – listing of section(s) that did not meet requirements and/or code extracts of sections that met requirements.
13. Critical Appraisal
SUB-TOTAL (T2)	5* =	4* =			3* =		2* =
Total Marks = T1 + T2

Case Study

The sleepy salon

The Problem

		ENTER		EXIT

Three hairdressers work independently in a salon shop:

The salon has 3 salon chairs, each of which is assigned to one hairdresser.

Due to budget restrictions, there are only 2 combs and 2 scissors in the salon.

Each hairdresser follows the same work plan:

· The hairdresser sleeps when no customer is waiting (and is not in the hairdresser's own chair).

· When the hairdresser is asleep, the hairdresser waits to be awakened by a new customer. (A sign in the shop indicates which salon has been asleep longest, so the customer will know which hairdresser to wake up if multiple hairdressers are asleep.)

· Once awake, the hairdresser cuts the hair of a customer in the hairdresser's chair.

· The hairdresser requires a comb and a pair of scissors to cut a customer’s hair. When the haircut is done, the customer pays the hairdresser and then is free to leave.

· After receiving payment, the hairdresser calls the next waiting customer (if any). If such a customer exists, that customer sits in the hairdresser's chair and the hairdresser starts the next haircut. If no customer is waiting, the hairdresser goes back to sleep.

Each customer follows the following sequence of events.

· When the customer first enters the salon, the customer leaves immediately if more than 20 people are waiting (10 standing and 10 sitting). On the other hand, if the salon is not too full, the customer enters and waits.

· If at least one hairdresser is sleeping, the customer looks at a sign, wakes up the hairdresser who has been sleeping the longest, and sits in that hairdresser 's chair (after the hairdresser has stood up).

· If all hairdressers are busy, the customer sits in a waiting-room chair, if one is available. Otherwise, the customer remains standing until a waiting-room chair becomes available.

· Customers keep track of their order, so the person sitting the longest is always the next customer to get a haircut.

· Similarly, standing customers remember their order, so the person standing the longest takes the next available waiting-room seat.

Deliverables:

For this exercise, you are to model the salon in FSP and write a Java program to simulate activity for this salon:

Simulate each hairdresser and each customer as a separate process.

Altogether, 30 customers should try to enter.

Use a random number generator, so a new customer arrives every 1, 2, 3, or 4 seconds. (This might be accomplished by an appropriate statement sleep (1+ (rand () %4)).

Similarly, use a random number generator, so each haircut lasts between 3 and 6 seconds.

Each hairdresser should report when he/she starts each haircut and when he/she finishes each haircut.

Each customer should report when he/she enters the salon. The customer also should report if he/she decides to leave immediately.

Similarly, if the customer must stand or sit in the waiting room, the customer should report when each activity begins.

Finally, the customer should report when the haircut begins and when the customer finally exits the shop.

Sample Output

In order to see what is happening dynamically you must have output from the Customers and the hairdressers reporting all their major events.

Add information about which process/thread is doing the output. This way you can see if a process/thread acts for another, which is strictly forbidden, but is a common error for Java solutions (objects are not processes!). An example of such incorrect behaviour is

Thread-Hairdresser: 21.31: Hairdresser1: Customer 3 is done!

main: 21.50: Hairdresser: Next customer please!

Thread-Customer-12 : 21.50: Customer12 is waiting for a chair.

Thread-Hairdresser: 21.31: Hairdresser2: Acquiring comb2!

Where you can see that not only the hairdresser thread but also the main thread is acting for the hairdresser.

Note that realistic time stamps are not required, it is fine to use any function to generate them.

You must not

• Kill a thread or process. You may not use any of the following primitives in Java:
• Thread.stop
• Thread.resume
• Thread.suspend
• Thread.interrupt
• setDaemon

You may not use the destroy or stop(0) primitives in - except to take care of temporary resources like simple timers.

If any of those primitives are found in your code, you will fail the assignment no matter the functionality of it.

• Solve the last orders problem in a manner forbidden in the description above.
• Resolve communication with an all-purpose one-channel solution.

Tips

• Run your program without customers entering the salon. This should work if your solution is correct. The solutions should not be dependent on the events created by the customers.
• Make very sure of who's actually doing the work. Make this easier for yourself by printing the name of the process performing an action.
• The use of semaphores (other than for controlling simple resources and basic mutex for statistics) is strongly discouraged.
• Use short delay times - there is no need for a simulation run to take more than 20-30 seconds.
• You do not need to implement a ticker.

Implementation

You should implement your simulation in Java.

Caution!

It might be tempting to use the Thread.interrupt() method to wake sleeping processes. This is a bad idea. Firstly, we have seen what a mess people can get into with this! Secondly, a behaviour which is present in every execution of the program is not exceptional, and is usually considered bad programming style to use an exception in such cases. In summary, don't use Thread.interrupt().

Documentation

The documentation should contain the following:

• Appropriate FSP statements.
• Appropriate LTS diagrams (you should used traces where applicable).
• Structure diagram where applicable.
• Requirements as seen from the marking scheme.
• UML class diagram of your implementation in Java (your source code must correspond against your UML class diagram).
• Explanation on sections of codes which you spent most time (include code extracts) on and also include discussion of section that did not work as expected.
• Other relevant discussions/diagrams.

• Describe any modifications, assumptions and basic design decisions that have been made about the behavior of the various components of the simulation.