Synchronization (Threads Accessing Shared Data)

Contents I.The Bank Transfer Problem II.Doing a Simulation on the Bank Transfer Problem III.New Requirement: A Transfer Must Wait Until There is Sufficient Fund IV.Deadlocks

I. The Bank Transfer Problem A bank manages a number of accounts Each account has an id (integer) and a balance The bank can  Open a new account with a given initial balance  Transfer an amount from an account to another account by using the ids. Overdraft is not allowed  Provide info about the balance total of all accounts  Provide info about the number of accounts

Solution 1. The Design 2. Developing openNewAccount() 3. Developing transfer() 4. Developing getBalanceTotal() 5. Developing getNumberOfAccounts()

1. The Design

2. Developing openNewAccount()

3. Developing transfer()

4. Developing calculateBalanceTotal()

5. Developing getNumberOfAccounts()

II. Doing a Simulation on Money Transfer If there are many transfer requests, the bank must arrange several front desks to serve several customers simultaneously Create a bank that contains 100 accounts. Each account has an initial balance of $1000 Create a separate thread for each account to transfer continuously a random amount (<= $1000) to a random account, then sleep for 100 ms  Insert a rather time consuming operation, say a print() command between the withdraw() and the deposit() operations  After a transfer, print out the balance total to check if this value is the same at any time

Solution 1. Developing a Single Thread Simulator 2. Making the Single Thread Simulator to Be Mutithreading 3. Observing the Race Condition 4. Solving the Race Condition Using An Explicit Lock 5. Solving the Race Condition Using synchronized (Implicit Lock)

1. Developing a Single Thread Simulator

1.1. Create a bank with 100 accounts

1.2. For Each Account, Make Infinite Random Transfers

1.3. Make transfer() more time consuming

Run the simulator to see the first account occupies the CPU time all the time

2. Making the Single Thread Simulator to Be Mutithreading

3. Observing the Race Condition 3.1. Observe the Balance Total 3.2. The Race Condition 3.3. Explain the Race Condition in the Simulation

3.1. Observe the Balance Total

3.2. The Race Condition When multiple threads have access to the same object and each calls a method that modifies the state of the object To void this race condition, we need to synchronize the access

3.3. Explain the Race Condition in the Simulation Thread 1 wants to transfer $500 and Thread2 wants to transfer $900 to the same account

The real problem is that the work of the transfer method can be interrupted in the middle. If we could ensure that the method runs to completion before the thread loses control, then the state of the bank account object would never be corrupted.

4. Solving the Race Condition Using An Explicit Lock The basic outline for protecting a code block with a ReentrantLock is: myLock.lock();//a ReentrantLock object try { critical section } finally { myLock.unlock(); //make sure the lock is // unlock even if an exception is thrown. }

4. Solving the Race Condition Using An Explicit Lock

5. Solving the Race Condition Using synchronized (Implicit Lock) If a method is declared with the synchronized keyword, then the object's lock protects the entire method.  That is, to call the method, a thread must acquire the intrinsic object lock.

 public synchronized void method() { method body }  public void method() { this.intrinsicLock.lock(); try { method body } finally { this.intrinsicLock.unlock(); } } }

5. Solving the Race Condition Using synchronized (Implicit Lock)

III. New Requirement: A Transfer Must Wait Until There is Sufficient Fund Modify the code so that when there is not enough money in the account to transfer, it must wait until some other thread has added funds. In the mean time, it must allow other threads a chance to make a deposit Note: This requirement is just aimed to introduce Condition Objects

public void transfer(int from, int to, double amount) { lock.lock(); try { Account fromAccount = … ; while(fromAccount.canWithdraw(amount)) { // wait … } // transfer … } finally { lock.unlock(); } } Now, what do we do when there is not enough money in the account?  We wait until some other thread has added funds.  But this thread has just gained exclusive access to the lock, no other thread has a chance to make a deposit.

Solution 1. Using a Lock and a Condition 2. Using synchronized

1. Using a Lock and a Condition

If the current thread call condition.await() :  The thread is now deactivated and gives up the lock. Another thread can increase the account balance.  The thread enters a wait set for that condition. It is not made runnable. It stays deactivated until another thread has called the signalAll method on the same condition. Only one thread in the wait set is again runnable and continues where it left off. In general, a call to wait should be inside a loop while(!(ok to proceed) condition.await();

2. Using synchronized

IV. Deadlocks

Unfortunately, there is nothing in the Java programming language to avoid or break deadlocks You must design your program to ensure that a deadlock situation cannot occur

Reference Core Java, Volume I - Fundamentals, Eighth Edition, Chapter 14. Cay S. Horstmann and Gary Cornell. Prentice Hall, 2008