when to use lock and when to use lockInterruptibly

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

when to use lock and when to use lockInterruptibly

Peter Veentjer - Anchor Men
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).

Met vriendelijke groet,

Peter Veentjer
Anchor Men Interactive Solutions - duidelijk in zakelijke
internetoplossingen

Praediniussingel 41
9711 AE Groningen

T: 050-3115222
F: 050-5891696
E: [hidden email]
I : www.anchormen.nl

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: when to use lock and when to use lockInterruptibly

Joe Bowbeer
On 11/29/05, Peter Veentjer - Anchor Men <[hidden email]> 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
InterruptedException.

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: when to use lock and when to use lockInterruptibly

David Holmes
In reply to this post by Peter Veentjer - Anchor Men
> 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).

If you want to be more responsive to interrupts *and* the acquisition of the
lock is not critical then you might want to always lockInterruptibly. A lot
of the time though that would force propagating the InterruptedException from
methods that are not truly "blocking" and hence don't need to be
interruptible.

One situation where you would not want to use interruptible locking is when
the action you need the lock for must be performed. eg:

   void somemethod() {
     try {
         // main code
      }
      finally {
         l.lock();
         try { updateState(); } finally {
         lock.unlock(); }
      }
   }

Cheers,
David Holmes
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest