Threads in Java - Reentrant Lock (Part 13)

A Reentrant Lock is nothing but an extension of the synchronized construct with a more controlled locking capability. It is unstructured unlike synchronized i.e. we don't have to use a block structure for locking and can even hold a lock across methods.

private ReentrantLock lock;

// Some code

public void A() {
    ...
    lock.lock();
    ...
}

public void B() {
    ...
    lock.unlock();
    ...
}

Clearly, the above flow is impossible to achieve via a single monitor in a synchronized construct.

Synchronized vs Reentrant Lock

In synchronized construct, a thread can take a lock only once and it does not have a mechanism of some waiting queue. So after the exit of one thread, any thread can take the lock. This may cause starvation of resources for some threads.

On the other hand, the ReentrantLock class implements the Lock interface and provides synchronization to methods while accessing shared resources. The locking mechanism is handled by the lock() and the unlock() methods and gives the lock to the current working thread and blocks all other threads.

The ReentrantLock also allows a thread to enter into lock more than once. Each time a thread does that, hold count is incremented by one. And for every unlock request, it is decremented by one. Once the hold count reaches to 0, the resource is unlocked.

Fairness parameter

 The constructor of the ReentrantLock also accepts a fairness parameter, which when set to true, grants access to the longest waiting thread. Using this locks favour granting access to the longest waiting thread. Otherwise, the lock does not guarantee any particular order. 

Programs using fair locks accessed by many threads may display lower overall throughput (i.e., are slower; often much slower) than those using the default setting, but have smaller variances in times to obtain locks and guarantee lack of starvation. Note, however, that fairness of locks does not guarantee fairness of thread scheduling. Thus, one of many threads using a fair lock may obtain it multiple times in succession while other active threads are not progressing and not currently holding the lock. Also, note that the untimed tryLock method does not honour the fairness setting. It will succeed if the lock is available even if other threads are waiting.

Code example

Below code demonstrates the usage of ReentrantLock in action. 

Here, there are two threads t1 and t2 are trying to access the shared getCount() method. The output of the above program will be

Thread-1 gets the count as: 0
Thread-0 gets the count as: 1
Thread-1 gets the count as: 2
Thread-0 gets the count as: 3
Thread-1 gets the count as: 4
Thread-0 gets the count as: 5

As you can see that each thread gets to access the shared getCount() method in synchronization.

Advantages of ReentrantLock

1. The lock can be accessed in an interruptible fashion
2. Ability to timeout while waiting for a lock
3. Can create a fair lock
4. Ability to try for a lock without waiting

Disadvantages

1. Makes code unreadable because of excessive use of try-finally block
2. Now programmer is responsible for acquiring and releasing lock which may introduce subtle bugs due to a programmer's error.

Conclusion

Congratulations!! 🙋 today we discussed ReentrantLock class in java with an example and its use cases. I hope you enjoyed this post.

You can find the complete code of this project on my GitHub in this commit. Feel free to fork or open issues, if any.

I would love to hear your thoughts on this and would like have suggestions from you to make it better. 

Feel free to befriend me on Facebook, Twitter or Linked In or say Hi by email.

Happy Coding 😊