CNT4714-Project 2  Solved

CNT 4714 – Project 2 
 

Title:  “Project 2:  An Application Employing Synchronized/Cooperating Multiple

Threads In Java Using Locks – A Banking Simulator”


Description:  In this programming assignment you will simulate the deposits and withdrawals made to a fictitious bank account (I’ll let you use my real bank account if you promise to make only deposits! J).  In this case the deposits and withdrawals will be made by synchronized threads.  Synchronization is required for two reasons – (1) mutual exclusion (updates cannot be lost) and (2) because a withdrawal cannot occur if the amount of the withdrawal request is greater than the current balance in the account.  This means that access to the account (the shared object) must be synchronized.  This application requires cooperation and communication amongst the various threads (cooperating synchronized threads).  (In other words, this problem is similar to the producer/consumer problem where there is more than one producer and more than one consumer process active simultaneously.)  If a withdrawal thread attempts to withdraw an amount greater than the current balance in the account – then it must block itself and wait until a deposit has occurred before it can try again.  As we covered in the lecture notes, this will require that the deposit threads signal all waiting withdrawal threads whenever a deposit is completed.
 

1.     To keep things relatively simple, as well as to see immediate results from a series of transactions (deposits and withdrawals), assume that deposits are made in amounts ranging from $1 to $250 (whole dollars only) and withdrawals are made in amounts ranging from $1 to $50 (again, whole dollars only).
 

2.     You should have four deposit threads and eight withdrawal threads simultaneously executing.   
 

3.     Once a deposit thread has executed, put it to sleep for few milliseconds (randomly generate this number – don’t use a constant sleep time) or so (depends a little bit on the speed of your system as to how long you will want to sleep the depositor threads - basically we want to ensure a lot more withdrawals than deposits) to allow other threads to execute.  This is the only situation in which a deposit thread will block.
 

4.     For withdrawal threads, things will be a bit different depending on whether you are working on a single or multi-core processor.
 

a.      For single core processors, once a withdrawal thread has executed, have it yield to another thread.  Since the thread is giving up the processor voluntarily, it will be unlikely to run again (attempt a second withdrawal in a row), before another thread runs.  Note however, that it does not prevent it from running again, if all other withdrawal threads are blocked and all depositors are sleeping, it will run again.

b.     For multi-core processors, once a withdrawal thread has executed, have it sleep for some random period of time (again, a few milliseconds should be fine).  Depending on which core a thread is executing, yielding the CPU won’t ensure that the same thread will not run again immediately.  While, sleeping the thread will also not ensure that it will not run two or more times in succession, it is less likely to do so in the multi-core environment.  

c.      What we don’t want to happen is a single withdrawal thread gaining the CPU and then executing a long sequence of withdrawal operations. Recall though that withdrawal threads block if they attempt to withdraw more than the current balance in the account.

d.     Similarly, we don’t want depositor threads monopolizing the CPU either and causing the balance in the account to grow continuously.  This would most likely occur when the withdrawal threads are sleeping too long in comparison to the average sleep time of the deposit threads.  See page 7 for an illustration of this.
 

5.     Assume all threads have the same priority.  Do not give different priority to depositor and withdrawal threads.
 

6.     The output from your program must look reasonably similar to the sample output shown below.   
 

7.     Do not put the threads into a counted loop for your simulation.  In other words, the run() method should be an infinite loop.  Just stop the simulation from your IDE after a few seconds.

 

8.     Do not use the Java synchronized statement.  I want you to handle the locking and signaling yourself.  No monitors!

 

9.     You must utilize a reentrant lock from the java.util.concurrent.locks package for implementing your locking protocols. We will specify no fairness policy for this application. Do not create your own lock using a Boolean or any other type of variable.