AllOrNothingLocks

credit for this assignment: Java Concurrency in Practice, Ben Choi, Miles Cushing, and Dennis Cosgrove

Motivation

In addition to Ordered Locks we can employ an all-or-nothing strategy for acquiring locks for mutual exclusion.

We gain experience with explicit locks and trying to acquire them and responding appropriately to success and failure.

Background

Check out the lock ordering studio.

In Java, locks are a synchronization tool that exists to ensure whatever is protected by the lock is only accessed one thread at a time, as to avoid a possible data race. In this studio we will explore the second type of locks: explicitly created Lock objects from the java.util.concurrent.locks package.

Every object has an intrinsic lock associated with the object, but Lock objects are explicitly defined and instantiated locks which can be called to lock or unlock. Lock objects are acted upon just like any other object, but we are mostly interested in the lock() method, the tryLock() method, and the unlock() method. For this studio, we will specifically use the ReentrantLock object, a class which implements the general Lock interface.

To demonstrate how to avoid both data races and deadlock issues, we will create a method designed to transfer money between two bank accounts. Two parties should be able to asynchronously and continuously transfer money between each other without a data race (courtesy of locks) or deadlock (something you will address).

For this approach, we will make use of the tryLock() method in order to attempt to acquire an object’s lock. If the object’s lock is not available at the time, we will continue to try to acquire the lock until it finally succeeds, after which we can successfully transfer funds from one bank account to another. In this approach, an asynchronous pair of transfers from A to B and B to A will not lead to deadlock as the two processes will give up on acquiring the lock until it becomes available, at which point it will finally acquire the lock. This approach does not make use of ordering, but simply relies on making lock attempts give up if the desired lock is not immediately available (and then try again later).

Java Util Concurrent

Refer to Oracle's official documentation for more information:

• Lock Objects Tutorial
• package java.util.concurrent.locks

• while loops
• finally
• Thread yield

• Lock
  • tryLock
  • unlock

• ReentrantLock
  • isHeldByCurrentThread

• ListIterator<E>
  • boolean hasNext()
  • E next()
  • boolean hasPrevious()
  • E previous()

Code To Implement

As mentioned in the background section, this implementation will avoid deadlock by giving up on acquiring a lock if it is not immediately available before coming back to it later (when it might actually be available). This implementation will need to make use of the ReentrantLocks associated with the sender and recipient bank account objects. More specifically, it will have to make use of the tryLock() method. For an example of how to format a tryLock, look below:

Lock lock = ...
if (lock.tryLock()) {
	try {
		doSomething();
	} finally {
		lock.unlock();
	}
}

BankAccountTryLocking

class:	BankAccountLockTrying.java
methods:	tryTransferMoney
package:	lock.allornothing.bank.studio
source folder:	student/src/main/java

method: public static TransferResult tryTransferMoney(AccountWithLock sender, AccountWithLock recipient, int amount) (thread-safe required)

Open BankAccountTryLocking.java.

A couple of notes and common issues:

• tryLock() will immediately give up and return false if the lock is not available when it is called. Thus, you will need to construct a loop that will continuously run until the desired lock is available. You can exit out of this loop in two ways: with the break keyword or by returning a valid value for the method. We do this for you so you will not need to write any loops.
• tryLock() will grab the lock if it can. There's no need to call lock() after tryLock().
• We recommend you call the TransferUtils.checkBalanceAndTransfer(sender, receiver, amount) method for the sake of simplicity. This method will check that the sender and recipient are not the same people and that the sender has enough money in her account to send the specified amount to the recipient.
• Anytime you lock a lock object, you should/must use a try/finally block to unlock the lock.
• Your implementation will have to make use of a nested try/finally block (one try/finally call within another).

LockUtils runWithAllLocksOrDontRunAtAll

class:	LockUtils.java
methods:	tryLockAll unlockAllHeldLocks runWithAllLocksOrDontRunAtAll
package:	lock.allornothing.util.studio
source folder:	student/src/main/java

method: private static boolean tryLockAll(List<ReentrantLock> locks) (sequential implementation only)

method: private static void unlockAll(List<ReentrantLock> locks) (sequential implementation only)

method: public static boolean runWithAllLocksOrDontRunAtAll(List<ReentrantLock> locks, Runnable body) (thread-safe required)

Note: in tryLockAll, you will need to call tryLock on all of the given locks. However, if one fails, you will need to unlock everything you have currently locked. A lock cannot be unlocked from a thread that doesn't hold the lock. Consider using the ListIterator interface.

Warning: If tryLockAll fails to acquire all of the locks, make sure to unlock any of the locks you did acquire.

Warning: If tryLockAll fails, when rolling back a ListIterator to unlock any locks you acquired, be sure to do an initial prev() to set the iterator in the correct location before looping through to unlock the rest.

Warning: An IllegalMonitorStateException() means that a thread tried to unlock a lock that it was not holding.

KitchenLockUtilsApp

class:	KitchenLockUtilsApp.java
methods:	executeRecipe
package:	lock.allornothing.kitchen.studio
source folder:	student/src/main/java

method: public static boolean executeRecipe(Recipe recipe) (sequential implementation only)

Open KitchenLockUtilsApp.java.

A couple of notes:

• An object of class Recipe contains a list of Appliances that it needs in order to complete the item. An object of class Appliance has a lock that you can use to make sure the method remains thread-safe.
• Use the recipe.create() method in order to actually execute the recipe. Caution: this method will throw an IllegalThreadStateException() if it is called without all the locks being held by the same thread that called the create method.
• Since it is unknown how many locks each recipe will need beforehand, make use of the LockUtils.runWithAllLocksOrDontRunAtAll(List<ReentrantLock> locks, Runnable body) method you wrote earlier.

Warning:The javadocs incorrectly refer to runWithAllLocks when runWithAllLocksOrDontRunAtAll is the correct method to invoke.

Testing Your Solution

Correctness

Complete

class:	TryLockingTestSuite.java
package:	lock.allornothing.studio
source folder:	testing/src/test/java

Individual

class:	BankTryLockingTestSuite.java
package:	lock.allornothing.bank.studio
source folder:	testing/src/test/java

class:	LockUtilsTestSuite.java
package:	lock.allornothing.studio
source folder:	testing/src/test/java

class:	KitchenTestSuite.java
package:	lock.allornothing.util.studio
source folder:	testing/src/test/java