Home :: Blogs :: sharadjava's blog

Java Concurrency Series- How to use Lock/RentrantLock in Java 5

By sharadjava - Posted on May 23rd, 2008
Tagged:  
Average: 5 (2 votes)

In this article, we will examine the subtleties of using newly introduced Lock classes in java.util.concurrent.locks package and their advantages over traditional "synchronized" blocks and methods.

The fact that a synchronized block of code is blocking in nature is one of the primary limitations. If two threads A and B call a consume and produce methods which act on the same resource, the second thread will block till the first one releases the lock. This limitation however provided a simplified way of writing multi-threaded code in Java, very helpful for beginners to understand and use when contrasted with POSIX pthread library in C/C++.

However, synchronized keyword does not provide a mechanism to check if another thread has obtained the lock or any means to attempt to lock. The wait/notify construct provides a means to coordinate between producer/consumer threads but one of them has to still wait, doing nothing, till it is notified.

Following code snippet shows a simple,non-optimized resource repository guarded by synchronized methods.

Code snippet 1.

  1. class ResourceRepositary {
  2.         private ArrayList<String> resourceRepositary= new ArrayList<String>();
  3.         public synchronized String consume() {
  4.                 String resource=null;
  5.                 if ( this.resourceRepositary.size()>0 )
  6.                 {
  7.                         resource =this.resourceRepositary.remove(this.resourceRepositary.size()-1);
  8.                 }
  9.                 return resource;
  10.                
  11.         }
  12.         public synchronized void produce(String resource) throws InterruptedException{
  13.                 this.resourceRepositary.add(resource);
  14.                 System.out.println("Blocking for 100 seconds");
  15.                 System.out.flush();
  16.                 Thread.sleep(100000);//sleep for 100 seconds
  17.                 System.out.println("UnBlocking ");
  18.         }
  19. }

If produce() and consume() methods are called from different threads, consume will block till produce() exits. ( assuming produce() is executed first ). The attached code sample has a method blockingExample() depicting this behavior.

Whereas changing the Resource repository to use RentrantLock instead of synchronized block will prevent the consume() from blocking. Thread executing consume() will not block, it will attempt to obtain the lock and will be unsuccessful if it's held by another thread. Agreed, this example isn't an effective example of the advantage we gain by tryLock(), but nevertheless conveys the idea.

Let's take another look at line 25-27 in code snippet 2. When we use Lock classes, we will have to follow this idiom of unlocking in the finally block to ensure unlocking. Folks from C++ will say deja vu, reminiscing "unlocking the mutex in the destructor" idiom.

Code Snippet 2

  1. class ResourceRepositaryWithLock extends ResourceRepositary {
  2.         private Lock lock=new ReentrantLock();
  3.         public String consume() {
  4.                 String resource=null;
  5.                 if (lock.tryLock()!=true )
  6.                 {
  7.                         return null;
  8.                 }
  9.                
  10.                 if ( this.resourceRepositary.size()>0 )
  11.                 {
  12.                         resource =this.resourceRepositary.remove(this.resourceRepositary.size()-1);
  13.                 }
  14.                 return resource;
  15.                
  16.         }
  17.         public void produce(String resource) throws InterruptedException{
  18.                 try {
  19.                         this.lock.lock();
  20.                         this.resourceRepositary.add(resource);
  21.                         System.out.println("Blocking for 100 seconds");
  22.                         System.out.flush();
  23.                         Thread.sleep(100000);// sleep for 100 seconds
  24.                         System.out.println("UnBlocking ");
  25.                 } finally {
  26.                         this.lock.unlock();
  27.                 }
  28.         }
  29. }

By using RentrantLock instance directly instead of Lock interface, we can access additional functionality in ReEntrantLock. ReEntrantLock has methods to find out the number of locks held.
As you might have expected, a thread can acquire the same lock multiple times ( definition of reentrant) but can unlock the lock completely with a single call to unlock().
Code Snippet 3

  1. class ResourceRepositaryWithRentrantLock extends ResourceRepositary {
  2.         private ReentrantLock reentrantLock=new ReentrantLock();
  3.         public String consume() {
  4.                 String resource = null;
  5.                 try {
  6.                         if (reentrantLock.tryLock() != true)
  7.                         {
  8.                                 int numberOfWaitingThreads = reentrantLock.getQueueLength();
  9.                                 System.out.println("NoOfWaitingThreads: "+ numberOfWaitingThreads);
  10.                                 if (numberOfWaitingThreads < 5)
  11.                                         reentrantLock.lock();
  12.                                 System.out.println("Do I own it"+ reentrantLock.isHeldByCurrentThread() );
  13.                                 System.out.println("Number of Locks owned by current Thread:"+ reentrantLock.getHoldCount());
  14.                                 reentrantLock.lock(); //thread holding the lock can obtain the lock again.
  15.                                 reentrantLock.lock(); //HoldCount will incremement with each lock() call.
  16.                                 System.out.println("Number of Locks owned by current Thread:"+ reentrantLock.getHoldCount());
  17.                         }
  18.                         if (this.resourceRepositary.size() > 0) {
  19.                                 resource = this.resourceRepositary
  20.                                                 .remove(this.resourceRepositary.size() - 1);
  21.                         }
  22.                 } finally {
  23.                         int lockCount=0;
  24.                         while( reentrantLock.isLocked() )
  25.                         {
  26.                                 reentrantLock.unlock(); //one unlock unlocks all the locks.
  27.                                 System.out.println("unlock count:"+  ++lockCount);
  28.                         }
  29.                 }
  30.                 return resource;
  31.         }
  32.         public void produce(String resource) throws InterruptedException{
  33.                 try {
  34.                         this.reentrantLock.lock();
  35.                         this.resourceRepositary.add(resource);
  36.                         System.out.println("Blocking for 100 seconds");
  37.                         System.out.flush();
  38.                         Thread.sleep(10000);// sleep for 100 seconds
  39.                         System.out.println("UnBlocking ");
  40.                 } finally {
  41.                         this.reentrantLock.unlock();
  42.                 }
  43.         }
  44. }

We can also use condition variables associated with the ReEntrantLock. With wait(), notifiy(), we were limited to one condition per lock object. With ReentrantLock, we can associate multiple conditions with the same lock object.
In code snippet 4, we have extended ResourceRepositaryWithRentrantLock to provide implementation of consume() and produce() that use conditions associated with reentrantLocks.

Code Snippet 4

  1.         private Condition resourceNotEmpty=this.reentrantLock.newCondition();
  2.         @Override
  3.         public void produce(String resource) throws InterruptedException{
  4.                 try {
  5.                         this.reentrantLock.lock();
  6.                         this.resourceRepositary.add(resource);
  7.                         System.out.println("signalling the fullfillment for condition:"+ resourceNotEmpty);
  8.                         resourceNotEmpty.signalAll();
  9.                         System.out.println("UnBlocking ");
  10.                 } finally {
  11.                         this.reentrantLock.unlock();
  12.                 }
  13.         }
  14.         @Override
  15.         public String consume() {
  16.                 String resource = null;
  17.                 try {
  18.                         reentrantLock.lock();
  19.                         while (this.resourceRepositary.size() == 0)
  20.                         {
  21.                                 this.resourceNotEmpty.await();//waiting for a condition to be true.
  22.                                 resource = this.resourceRepositary.remove(this.resourceRepositary.size() - 1);

Additionally Condition class provides methods to get into uniterruptable wait states, timed wait states etc.
This API javadocs provide good explantion. http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/locks/Condi...

Resources:
Brian Goetz's "Java Concurrency in Practise"
http://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/dp/032134960...

Code download:
The entire code can be downloaded from the attachment below. It has been compiled and run using Java 1.5.03. The code sample has additional comments and print statements, which will help us grasp the concepts. I would strongly recommend walking through the code along with reading the article.

In the next article, we will tackle Atomic variables in the package java.util.concurrent.atomic

Thanks and keep checking www.techgrasp.com

Bookmark/Search this post with:
  • Delicious
  • Digg
  • StumbleUpon
  • Propeller
  • Reddit
  • Magnoliacom
  • Newsvine
  • Furl
  • Facebook
  • Google
  • Yahoo
  • Technorati
  • Icerocket
lock() before/after try
Submitted by Anonymous on Tue, 05/27/2008 - 10:01.

Isn't it supposed to be as follows, lock() being before try, because you only need to unlock(); if lock() succeeded:

  1. reentrantLock.lock();
  2. try {
  3.    // ...
  4. } finally {
  5.    reentrantLock.unlock();
  6. }

I'm not sure whether unlock() may be called when the current thread does not have the lock. The Javadocs don't say anything about that.

The semantics for read/write lock upgrading are a lot more "fun" though, here's an example for initializing a cache (e.g. a HashMap) on demand:

  1. readWriteLock.readLock().lock();
  2. try {
  3.    if (cache == null) {
  4.       // upgrade lock from read to write, must first abandon the read lock
  5.       readWriteLock.readLock().unlock();
  6.       // and then acquire the write lock
  7.       readWriteLock.writeLock().lock();
  8.       try {
  9.          // and then check again, as another thread may have gotten
  10.          // the write lock first
  11.          if (cache == null) {
  12.             // we now have the write lock first and the cache is still uninitialized,
  13.             // we can now safely build it up
  14.             cache = initializeCache();
  15.          }
  16.       } finally {
  17.          // re-acquire the read lock ...
  18.          readWriteLock.readLock().lock();
  19.          // ... and give up the write lock
  20.          readWriteLock.writeLock().unlock();
  21.       }
  22.    }
  23.  
  24.    // ... do something with the cache
  25.    return cache.get(key);
  26.  
  27. } finally {
  28.    // give up the read lock
  29.    readWriteLock.readLock().unlock();
  30. }

Post new comment

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
A
s
Z
g
2
x
Enter the code without spaces and pay attention to upper/lower case.