In this project 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 user

agents $($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 agents $($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 agent

attempts to withdraw an amount greater than the current balance in the account $$ then

it must block itself and wait until a depositing agent has added money to the account

before it can try again. As we covered in the lecture notes, this will require that the

depositing agents signal all waiting withdrawing agents whenever a deposit is

completed.

$1.$ You should have five depositor agents $($threads$)$ and ten withdrawal agents

$($threads$),$ and two auditor agents $($threads$)$ simultaneously executing. Use a

FixedThreadPool$()$ and an Executor object to control the threads.

$2.$ To keep things relatively simple, assume that deposits are made in amounts

ranging from $$1$ to $$500($whole dollars only$)$ and withdrawals are made in

amounts ranging from $$1$ to $$99($again$,$ whole dollars only$).$ Since we have

more withdrawal threads than depositor threads, the account balance should

constantly decrease over time. This will lead to withdrawal agents repeatedly

blocking for insufficient funds. Start the simulation with a balance of $$0$ in the

account.

CNT $4714$ Project $2$ Spring $2024$

Page $2$

$3.$ Once a depositor agent $($thread$)$ has deposited into the account, 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 depositing threads $-$ basically we want to ensure a lot more

withdrawals than deposits$)$ to allow other agents to execute.

$4.$ For withdrawal agents, 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 agent has withdrawn funds

from the account, have it yield the processor unit. Since the agent is giving

up the processor voluntarily, it will be unlikely to run again $($attempt a

second withdrawal in a row$),$ before another agent runs. Note however,

that it does not prevent it from running again, if all other withdrawal

agents are blocked and all depositors are sleeping, it will run again. So

occasional back$-$to$-$back runs of withdrawal agents might occur $($see

below$).$

b$.$ For multi$-$core processors, once a withdrawal agent 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 agent gaining the

CPU and then executing a long sequence of withdrawal operations. Recall

though, that withdrawal agents block if they attempt to withdraw more

than the current balance in the account.

d$.$ Similarly, we don$$t want depositor agents monopolizing the CPU either

and causing the balance in the account to grow continuously. This would

most likely occur when the withdrawal agents are sleeping too long in

comparison to the average sleep time of the depositing agents. See page

$11$ for an illustration of this.

$5.$ Assume all depositor, withdrawal, and auditor agents have the same priority. Do

not give different priority to depositor, withdrawal, and auditor agents $($threads$).$

The auditor agents will also have normal priority and will simply run less

frequently than the depositor and withdrawal threads $($i$.$e$.,$ the auditor agents will

sleep longer between runs than either depositor or withdrawal agents$).$ See

below.

Page $3$

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

shown below. The simulation output should show the action of each agent along

with the account balance produced by the agent$$s transaction and the transaction

number.

$7.$ Do not put the threads into a counted loop for your simulation. In other

words, the run$()$ method for all threads should be an infinite loop. Just stop

the simulation from your IDE after a few seconds.

$8.$ Do not use the Java synchroniDo not use the Java synchronized statement. I want you to handle the loc