This week's book giveaway is in the OCPJP forum.
We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line!
See this thread for details.
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 OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "ReentrantLock - lock vs lockInterruptibly" Watch "ReentrantLock - lock vs lockInterruptibly" New topic
Author

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

whereas,

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 ?

Regards,

Pho
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
Bartender

Joined: Jan 28, 2003
Posts: 4181
    
  21

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.


Steve
Nitesh Kant
Bartender

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: http://aspose.com/file-tools
 
subject: ReentrantLock - lock vs lockInterruptibly