Page 1 Title: “Project 2: An Application Employing Synchronized/Cooperating Multiple Threads In Java Using Locks – A Banking Simulator” Points: 100 points Due Date: Sunday June 14, 2020 by 11:59 pm (WebCourses time) 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 (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 depositor threads signal all waiting withdrawal threads whenever a deposit is completed. 1. You should have five depositor threads and nine withdrawal threads simultaneously executing. 2. 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). Since we have more withdrawal threads than depositor threads, the account balance should constantly decrease over time. 3. Once a depositor 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 CNT 4714 – Project 2 – Summer 2020 Page 2 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 anot.

1. Page 1
Title: “Project 2: An Application Employing
Synchronized/Cooperating Multiple
Threads In Java Using Locks – A Banking Simulator”
Points: 100 points
Due Date: Sunday June 14, 2020 by 11:59 pm (WebCourses
time)
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 (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

2. 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
depositor threads signal all
waiting withdrawal threads whenever a deposit is completed.
1. You should have five depositor threads and nine withdrawal
threads
simultaneously executing.
2. 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). Since we have more withdrawal threads than depositor
threads, the
account balance should constantly decrease over time.
3. Once a depositor thread has executed, put it to sleep for few
milliseconds
(randomly generate this number – don’t use a constant sleep
time) or so

3. (depends a little bit on the speed of your system as to how long
you will want
CNT 4714 – Project 2 – Summer 2020
Page 2
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. So occasional
back-to-
back runs of withdrawal threads might occur.
b. For multi-core processors, once a withdrawal thread has

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

5. 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.
Page 3
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.
References:
Notes: Lecture Notes for Multithreaded Applications.
Restrictions:

6. Your source files shall begin with comments containing the
following information:
/* Name:
Course: CNT 4714 Summer 2020
Assignment title: Project 2 – Synchronized, Cooperating
Threads Under Locking
Due Date: June 14, 2020
*/
Input Specification: Internal to the program.
Output Specification: Console based. Your output should
appear reasonably
similar to the output shown below.
Deliverables:
(1) Zip up all of your .java files and submit them via
WebCourses no later than
11:59pm Sunday June 14, 2020.
(2) Include at least one screen shot which illustrates the
execution of your
synchronized threaded application. See below for some
representative
examples. You can either do a screen shot of the console
window like I did
below or redirect your output to a file and take a screen shot
from an editor.
Additional Information:

7. Shown below are three example screen shots of the output from
this program to help
illustrate how your application is to operate and display the
results. The last page
illustrates execution runs that you do not want to produce.
Page 4
Two withdrawal
threads blocked due
to insufficient funds.
Page 5
Withdrawal thread W5
runs three times in a row.
This is ok. It may
happened from time to
time.
Page 6
All withdrawal threads are
blocked. No withdrawal

8. thread can run until a
depositor thread runs.
Page 7
We don’t want to see this sort of scenario where the depositors
are monopolizing the
account. Indication is the depositor threads aren’t sleeping long
enough or the
withdrawal threads are sleeping too long.
Balance just continues to
grow and no blocking ever
occurs.
DAT/565 v3
Market Analysis Research
DAT/565 v3
Page 2 of 2
Wk 3 Market Analysis ResearchSection 1 - Business overview,
mission and vision
Describe the proposed business. Address the following in your
summary:
· What type of product/service will it offer?
· What is the intended market?
· What is the business model?
Articulate the business’s mission and vision statements.
Section 2 - Market analysis

9. Based on your intended product or service, describe the
characteristics of your customer base.
Investigate and list your current competitors. For example, if
you’re manufacturing and selling exercise equipment, current
competitors would be companies like NordicTrack or Nautilus,
Inc. To simplify the process, limit yourself to businesses you
are competing directly against. If your business is a local bistro,
then your competitors are other local similar restaurants.
Research and estimate the size of your intended market. Market
size is the number of potential customers or unit sales for your
products/services. Consider the nature of your business when
researching market size. For instance, if your business is a local
bistro, then your market size is determined by the population
within a reasonable radius of the restaurant, say, 5-15 miles
maximum. On the other hand, if your business intends to sell a
low-weight mountain bicycle online, then the market size is the
average number of low-weight mountain bicycles sold
nationwide annually.
Estimate the value of your market. Market value is the potential
revenues the market has to offer. For instance, suppose low-
weight mountain bicycles have a market size of 300,000 units a
year with a $500 average price. Then the market value would be
$150,000,000.
It can be difficult to estimate market value as you must make
assumptions related to market size and average unit price. Use
the expected value concept introduced in Chapter 6 of the
textbook and the chart below to do the estimation.
Expected Market Value: Mountain Bicycle Scenario
Assumptions
Probability p(x)
Units ('000)
Avg. Unit Price ($)

10. Market Value ('$000)
Pessimistic
0.30
200
450
90,000
Most Likely
0.50
300
500
150,000
Optimistic
0.20
375
550
206,250
Expected Market Value ('$000)
102,110
Estimate the total addressable market or TAM. This is the
fraction of the total market you realistically estimate to get.
Most businesses have a relatively modest market share, well
under 20%. For example, if we expect to get a 5% share of the
mountain bicycle market, then our TAM would be: 0.05 *
$102,110,000 = $5,105,500 or approximately $5.1 million.
Section 3: Recommendation
Based on the information collected, do you feel it is a good idea
to continue with the implementation of the business? Explain
why or why not.
Cite references to support your assignment.

11. Format your citations according to APA guidelines.
Copyright 2020 by University of Phoenix. All rights reserved.
Copyright 2020 by University of Phoenix. All rights reserved.