Reference no: EM131310211

Assignment: Multi-threaded Programming in Java Using Locks

Objectives: To practice programming cooperating, synchronized multiple threads of execution.

Description: In this programming assignment you will simulate the deposits and withdrawals made to a fictitious bank account. In this case synchronized threads will make the deposits and withdrawals. 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 - then it must block 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 $200 (even dollars only) and withdrawals are made in amounts ranging from $1 to $50 (again, even dollars only).

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

3. Once a deposit thread has executed, put it to sleep for a millisecond 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. Once a withdrawal thread has executed, have it yield to another thread (don't put it to sleep though). This will prevent a single withdrawal thread from gaining the CPU and then executing a long sequence of withdrawal operations.

Withdrawal threads block if they attempt to withdraw more than the current balance in the account.

5. Assume all threads have the same priority.

6. The output from your program must look reasonably.

7. Do not put the threads into a counted loop for your simulation. In other words, the run() method should be an infinite loop.

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

References:

Notes: Lecture Notes for Multithreaded Applications.

Input Specification: Internal to the program.