[concurrency-interest] when to use lock and when to use lockInterruptibly

Joe Bowbeer joe.bowbeer at gmail.com
Tue Nov 29 07:06:02 EST 2005

On 11/29/05, Peter Veentjer - Anchor Men <p.veentjer at anchormen.nl> wrote:
> When should a lockInterruptibly be used instead of a lock? I guess it
> depends on the lock implementation if it supports interruption. Is this
> correct? And wouldn`t it be better to always you the lockInterruptibly
> (although you have to deal with an InterruptedException).

The non-interruptible lock method is similar to the implicit lock in a
"native" synchronized block, in that neither can be interrupted.  I
believe this is one of the reasons that non-interruptible is the
default for the Lock interface.

(Note that the acquire method was interruptible in the dl.u.c. Sync
interface, Lock's ancestor.)

For other situations, that is, except when replacing native
synchronized blocks or otherwise retrofitting old methods with new
locks, I tend to favor lockInterruptibly and its explicit

More information about the Concurrency-interest mailing list