my dog learned polymorphism*
The moose likes Threads and Synchronization and the fly likes ReentrantLock - lock vs lockInterruptibly Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "ReentrantLock - lock vs lockInterruptibly" Watch "ReentrantLock - lock vs lockInterruptibly" New topic

ReentrantLock - lock vs lockInterruptibly

Pho Tek
Ranch Hand

Joined: Nov 05, 2000
Posts: 761

One difference I've noticed is this:-

lock does NOT throw InterruptedException


lockInterruptibly throws an InterruptedException

I then looked into how ArrayBlockingQueue is using it.

Does this mean that if a thread is blocked on lock.lock(), the thread is screwed because lock() is not interruptible ? What is the utility of a non-interruptible lock ?


Carey Evans
Ranch Hand

Joined: May 27, 2008
Posts: 225

The locks used by the synchronized keyword are not interruptible either, so the lock() method is just as good or bad as the built-in locks. In the case of ArrayBlockingQueue, the locked code won�t take very long, so it doesn�t matter.
Steve Luke

Joined: Jan 28, 2003
Posts: 4165

Originally posted by Pho Tek:
Does this mean that if a thread is blocked on lock.lock(), the thread is screwed because lock() is not interruptible ? What is the utility of a non-interruptible lock ?

The un-interruptable lock will block when lock.lock() gets called until the thread that currently owns the lock releases it. If the thread that currently owns the lock never releases it then this thread can't get the lock and will be blocked forever. This is analogous to the normal operation of the synchronized (object) { } block. The method will block while trying to get a lock on the object, when it does it proceeds.

So the question I would have is when is it important to force a thread to interrupt while it is acquiring a lock?

It doesn't mean that any code between the lock() and unlock() commands can't be interrupted. Any of the actions between the locks can be interrupted as normal.

Nitesh Kant

Joined: Feb 25, 2007
Posts: 1638

Regarding the BlockingQueue implementation, you will notice that there are two offer methods in there. One that throws an InterruptedException and the other that does not.
In the one that throws an InterruptedException it uses lockInterruptibly() and the other one it uses lock().
So, the kind of lock you use will typically depend on what behavior you want your code to exhibit. Making an assumption that everyone will use a interruptable lock implementation would not have been correct because many people do not really need that.
For instance, if i do not have any way to interrupt a thread in my application then why will I go for interruptable locks.

I am not sure whether performance wise interruptible and non interruptable locks are different. May be the gurus of multi-threading will have a say!

apigee, a better way to API!
I agree. Here's the link:
subject: ReentrantLock - lock vs lockInterruptibly
Similar Threads
Denny's DVD ReservationsManager - signal()
Question about working of ReentrantLock
Basic multiple locks in one class question
using ReentrantLock to model a Semaphore