In-Class Exrercise-6: (10 Marks) Deadlock Resolution: Our basic understanding, using synchronized keywords to synchronize critical methods should resolve all problems. Let’s imagine that we have two...

inn file


In-Class Exrercise-6: (10 Marks) Deadlock Resolution: Our basic understanding, using synchronized keywords to synchronize critical methods should resolve all problems. Let’s imagine that we have two accounts that can deposit, withdraw, and transfer to another account. What happens if at the same time we want to transfer money from one account to another and vice versa? Let’s look at an example. // // DeadlockAccounts.java // public class DeadlockAccounts { public static void main(String[] args) throws InterruptedException { class Account { int balance = 100; public Account(int balance) { this.balance = balance; } public synchronized void deposit(int amount) { balance += amount; } public synchronized boolean withdraw(int amount) { if (balance >= amount) { balance -= amount; return true; } return false; } public synchronized boolean transfer(Account destination, int amount) { if (balance >= amount) { balance -= amount; synchronized(destination) { destination.balance += amount; }; return true; } return false; } public int getBalance() { return balance; } } final Account bob = new Account(200000); final Account joe = new Account(300000); class FirstTransfer extends Thread { public void run() { for (int i = 0; i < 100000;="" i++)="" {="" bob.transfer(joe,="" 2);="" }="" }="" }="" class="" secondtransfer="" extends="" thread="" {="" public="" void="" run()="" {="" for="" (int="" i="0;" i="">< 100000; i++) { joe.transfer(bob, 1); } } } firsttransfer thread1 = new firsttransfer(); secondtransfer thread2 = new secondtransfer(); thread1.start(); thread2.start(); thread1.join(); thread2.join(); system.out.println("bob's balance: " + bob.getbalance()); system.out.println("joe's balance: " + joe.getbalance()); } } when we run the above program on our machine it usually gets stuck. why does this happen? if we look closely, we can see that when we transfer money, we are entering into the transfer method that is synchronized and locks access to all synchronized methods on the source account, and then locks destination account which locks access to all synchronized methods on it. this scenario is illustrated in the figure below: consider the following scenario: • first thread calls transfer on bob’s account to joe’s account • second thread calls transfer on joe’s account to bob’s account • second thread decreases amount from joe’s account • second thread goes to deposit amount to bob’s account but waits for first thread to complete transfer. • first thread decreases amount from bob’s account • first thread goes to deposit amount to joe’s account but waits for second thread to complete transfer. in this scenario, one thread is waiting for another thread to finish transfer and vice versa. they are stuck with each other, and the program cannot continue. thus, deadlock occurs. to avoid deadlock it is necessary to lock accounts in the same order. to fix the program we’ll give each account a unique number so that we can lock accounts in the same order when transferring the money. write the deadlock resolved version of the above program. deliverable: 1. report (2 marks) 2. source code (8 marks) sample output: 100000;="" i++)="" {="" joe.transfer(bob,="" 1);="" }="" }="" }="" firsttransfer="" thread1="new" firsttransfer();="" secondtransfer="" thread2="new" secondtransfer();="" thread1.start();="" thread2.start();="" thread1.join();="" thread2.join();="" system.out.println("bob's="" balance:="" "="" +="" bob.getbalance());="" system.out.println("joe's="" balance:="" "="" +="" joe.getbalance());="" }="" }="" when="" we="" run="" the="" above="" program="" on="" our="" machine="" it="" usually="" gets="" stuck.="" why="" does="" this="" happen?="" if="" we="" look="" closely,="" we="" can="" see="" that="" when="" we="" transfer="" money,="" we="" are="" entering="" into="" the="" transfer="" method="" that="" is="" synchronized="" and="" locks="" access="" to="" all="" synchronized="" methods="" on="" the="" source="" account,="" and="" then="" locks="" destination="" account="" which="" locks="" access="" to="" all="" synchronized="" methods="" on="" it.="" this="" scenario="" is="" illustrated="" in="" the="" figure="" below:="" consider="" the="" following="" scenario:="" •="" first="" thread="" calls="" transfer="" on="" bob’s="" account="" to="" joe’s="" account="" •="" second="" thread="" calls="" transfer="" on="" joe’s="" account="" to="" bob’s="" account="" •="" second="" thread="" decreases="" amount="" from="" joe’s="" account="" •="" second="" thread="" goes="" to="" deposit="" amount="" to="" bob’s="" account="" but="" waits="" for="" first="" thread="" to="" complete="" transfer.="" •="" first="" thread="" decreases="" amount="" from="" bob’s="" account="" •="" first="" thread="" goes="" to="" deposit="" amount="" to="" joe’s="" account="" but="" waits="" for="" second="" thread="" to="" complete="" transfer.="" in="" this="" scenario,="" one="" thread="" is="" waiting="" for="" another="" thread="" to="" finish="" transfer="" and="" vice="" versa.="" they="" are="" stuck="" with="" each="" other,="" and="" the="" program="" cannot="" continue.="" thus,="" deadlock="" occurs.="" to="" avoid="" deadlock="" it="" is="" necessary="" to="" lock="" accounts="" in="" the="" same="" order.="" to="" fix="" the="" program="" we’ll="" give="" each="" account="" a="" unique="" number="" so="" that="" we="" can="" lock="" accounts="" in="" the="" same="" order="" when="" transferring="" the="" money.="" write="" the="" deadlock="" resolved="" version="" of="" the="" above="" program.="" deliverable:="" 1.="" report="" (2="" marks)="" 2.="" source="" code="" (8="" marks)="" sample="">