• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Devaka Cooray
  • Knute Snortum
  • Paul Clapham
  • Tim Cooke
Sheriffs:
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Bear Bibeault
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Ron McLeod
  • Piet Souris
  • Frits Walraven
Bartenders:
  • Ganesh Patekar
  • Tim Holloway
  • salvin francis

ReentrantLock - lock vs lockInterruptibly  RSS feed

 
Ranch Hand
Posts: 782
Chrome Python Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 225
Debian Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Bartender
Posts: 4179
22
IntelliJ IDE Java Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.
 
Bartender
Posts: 1638
IntelliJ IDE Java MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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!
 
Destiny's powerful hand has made the bed of my future. And this tiny ad:
how do I do my own kindle-like thing - without amazon
https://coderanch.com/t/711421/engineering/kindle-amazon
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!