Concurrent Programming - CT074-3-2 Asia Pacific University of Technology & Innovation Level 2

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:

 Appropriateness of coding techniques used to implement design

 Appropriateness of the Java concurrent programming facilities used
 Program runs appropriately
 Appropriateness of Class Diagram
 Usefulness of instructions for compiling and running the program including comment
lines in source codes.
 Presentation of the source code listings – except UI-related codes
 Discussion of the safety aspects of multi-threaded system implemented
 Discussion of encapsulation implemented
 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.

Page 1 of 7
 Concurrent Programming - CT074-3-2 Asia Pacific University of Technology & Innovation Level 2

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 (Lower): As above, plus your presentation is clear, well organised and prepared.

o Credit (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 Distinction: 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 (Lower): As above, plus the system provided meets all expected functionality.

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

o Distinction: 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 (Lower): As above, plus you must provide one of a test report or discussion which
shows that your system is free from data corruption and deadlock.
o Credit (Upper): As above, plus you must provide discussion that shows that your system is
free from data corruption and deadlock.
o Distinction: As above, plus the report must be among the best in the class, and must stand
out from the other reports in your class.

Page 2 of 7
Concurrent Programming - CT074-3-2 Asia Pacific University of Technology & Innovation Level 2

MARKING SCHEME

Marks (10 marks for each criteria below)

Criteria Very
Excellent Good Average Poor
Poor
(8-10) (6-7) (5) (3-4)
(0-1)
1. Introduction and background
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 Class Diagram

SUB-TOTAL (T1)

Marks (10 marks for each criteria below)

Very
Criteria Excellent Good Average Poor
Poor
(8-10) (6-7) (5) (3-4)
(0-1)
6. Usefulness of instructions for
compiling and running the program
including comment lines in source
codes.
7. Discussion of the safety aspects of
multi-threaded system implemented
8. Discussion of encapsulation
implemented
9. Reporting of appropriate tests of
program execution
10. Depth of discussion – listing of
section(s) that did not meet
requirements and/or code extracts of
sections that met requirements.

SUB-TOTAL (T2)

Total Marks = (T1 + T2)

Page 3 of 7
Concurrent Programming - CT074-3-2 Asia Pacific University of Technology & Innovation Level 2

Case Study
The sleepy salon
The Problem

Standing area Standing area

Three salon chairs

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.
(Any available hairdresser can be told 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.

Page 4 of 7
Concurrent Programming - CT074-3-2 Asia Pacific University of Technology & Innovation Level 2

 If at least one hairdresser is sleeping, the customer wakes up the hairdresser who is
sleeping, 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 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.

Page 5 of 7
Concurrent Programming - CT074-3-2 Asia Pacific University of Technology & Innovation Level 2

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:
o Thread.stop
o Thread.resume
o Thread.suspend
o Thread.interrupt

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

Page 6 of 7
Concurrent Programming - CT074-3-2 Asia Pacific University of Technology & Innovation Level 2

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:

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

Page 7 of 7