java search
Loading
Help improve Java Search

Tuesday, November 21, 2006

Java 5 Concurrency: Locks

he standard way of obtaining locks till Java 1.4 was by the use of synchronized keyword, while it was simple, it also has a number of limitations:
  • No way to back off from an attempt to acquire a lock that is already held, or to give up after waiting for a specified period of time, or to cancel a lock attempt after an interrupt.
  • No way to alter the semantics of a lock, for example, with respect to reentrancy, read versus write protection, or fairness.
  • The use of synchronized forces all lock acquisition and release to occur in a block-structured way: when multiple locks are acquired they must be released in the opposite order, and all locks must be released in the same lexical scope in which they were acquired.
The java.util.concurrent.locks package provides a high-performance lock implementation, which supports specifying a timeout when attempting to acquire a lock, multiple condition variables per lock, non-lexically scoped locks, and support for interrupting threads which are waiting to acquire a lock.
Skip to Sample Code.
The java.util.concurrent.lock package provides a framework for locking and waiting for conditions that is distinct from built-in synchronization and monitors.

The Lock interface supports locking disciplines that offer different locking semantics (reentrant, fair, etc), and that can be used in non-block-structured contexts including hand-over-hand and lock reordering algorithms. For example, some algorithms for traversing concurrently accessed data structures require the use of "hand-over-hand" or "chain locking": you acquire the lock of node A, then node B, then release A and acquire C, then release B and acquire D and so on. Implementations of the Lock interface enable the use of such techniques by allowing a lock to be acquired and released in different scopes, and allowing multiple locks to be acquired and released in any order.
public interface Lock {
void lock();
void lockInterruptibly() throws InterruptedException;
boolean tryLock();
boolean tryLock(long time, TimeUnit unit) throws InterruptedException;
void unlock();
Condition newCondition();
}
The lock() method waits uninterruptably for the lock to be acquired, while the lockInterruptably() method is interruptable. The tryLock() method tries to obtain the lock at the time of invocation, if not it returns false. The tryLock(time, unit), tries to obtain the lock at the time of invocation and waits till timeout or till it is interrupted. The lock() method is not interruptible, all the others are interruptible.
Since the automatic unlocking feature available with synchronized method is unavailable with the new locking mechanism, we have to explicitly unlock. This has to be done in same way we close the I/O streams or JDBC connections
Lock l = ...;
l.lock();
try {
// access the resource protected by this lock
} finally {
l.unlock();
}
This works with the lock() method, but may throw exceptions when used with tryLock() as demonstrated in the example below.
ReentrantLock is the primary implementation class for the Lock interface. The following sample code demonstrates the use of ReentrantLock.
public class ReentrantThread implements Runnable {
private static final ReentrantLock lock = new ReentrantLock(false);
public static String sharedVariable = "";
public void run() {
for (int i = 0; i < 10; i++) {
try {
if (lock.tryLock(1, TimeUnit.MILLISECONDS)) { // Lock obtained
System.out.println("Lock Obtained by thread : " + Thread.currentThread().getName());
sharedVariable += Thread.currentThread().getName() + " : locked \t" + i + "\n";
} else { // Lock not obtained
sharedVariable += Thread.currentThread().getName() + " : unlocked \t" + i + "\n";
}
Thread.sleep(1);
} catch (Exception e) {
e.printStackTrace();
} finally {
if(lock.isLocked()) {
lock.unlock();
}
}
}
}
}
ReentrantThread.java

Note that in the finally block, lock.isHeldByCurrentThread() was used. This was necessary, since the tryLock() method may exit without obtaining the lock, in this case, trying to unlock the thread will result in an IllegalMonitorStateException.
public class LockTester {
public static void main(String[] args) {
Thread t1 = new Thread(new ReentrantThread(), "thread1");
Thread t2 = new Thread(new ReentrantThread(), "thread2");
Thread t3 = new Thread(new ReentrantThread(), "thread3");
t1.start();
t2.start();
t3.start();
try {
t1.join();
t2.join();
t3.join();
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println(ReentrantThread.sharedVariable);
}
}
LockTester.java
The next post discusses the usage of Read/Write Locks.

1 comment:

  1. It is April 2010, and the post is still useful: it was written very well; When it is run, the output is quite educational

    ReplyDelete