RE: when to use lock and when to uselockInterruptibly

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

RE: when to use lock and when to uselockInterruptibly

Peter Veentjer - Anchor Men
Thanks Joe and David.

But what do you mean with?
========================================
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.
========================================
With a lock() you always get the lock? What if the thread is interrupted
while it wants to acquire a lock with the lock() method. What is going
to happen? With a lockInterruptibly() a InterruptedException is thrown.
But what happens with a normal lock() method?

-----Oorspronkelijk bericht-----
Van: [hidden email]
[mailto:[hidden email]] Namens David Holmes
Verzonden: woensdag 30 november 2005 0:13
Aan: [hidden email]
Onderwerp: Re: [concurrency-interest] when to use lock and when to
uselockInterruptibly

> 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

_______________________________________________
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 touselockInterruptibly

Dawid Kurzyniec
Peter Veentjer - Anchor Men wrote:

>With a lock() you always get the lock? What if the thread is interrupted
>while it wants to acquire a lock with the lock() method. What is going
>to happen? With a lockInterruptibly() a InterruptedException is thrown.
>But what happens with a normal lock() method?
>
>  
>
Essentially, nothing - at least until the lock is obtained, and some
operation later tests the status of the interruption flag. Interrupting
a thread merely sets the "interrupted" status flag to true; whether and
when the thread responds to interruption is up to that thread. Certain
methods, like Object.wait(), Thread.sleep(), Lock.lockInterruptibly(),
and Condition.await(), are responsive to interruption, and will throw
InterruptedException if the "interrupted" flag is set upon invocation or
becomes set while the thread is blocked. In other situations, e.g. if a
thread is blocked on "synchronized", lock.lock(),
Condition.awaitUninterruptibly(), or I/O operation, or simply if is not
blocked at all, the interruption requests do not cause any immediate
action except for setting the flag.

Basically, lock.lock() cannot complete in any other way than
successfully obtaining the lock; the only other way is to kill the JVM.

Regards,
Dawid

_______________________________________________
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 touselockInterruptibly

David Holmes
In reply to this post by Peter Veentjer - Anchor Men
Peter,

> But what do you mean with?
> ========================================
> 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.
> ========================================

If you are acquiring the lock before doing anything significant then you
could choose to make the lock acquisition interruptible, thereby making your
thread more responsive to interruption. But you then have to propagate the
exception and that impacts the design of the API - a design where locking is
an implementation concern and the (short) blocking associated with that is
not something that necessarily the API should reflect.

If the action you are acquiring the lock for absolutely must be carried out
then there is no point making the lock acquisition interruptible.

> With a lock() you always get the lock? What if the thread is interrupted
> while it wants to acquire a lock with the lock() method. What is going
> to happen? With a lockInterruptibly() a InterruptedException is thrown.
> But what happens with a normal lock() method?

As Dawid said the normal lock() method will only return once the lock has
been acquired, and it always returns normally. If you get interrupted while
trying to acquire it then you remain with your interrupt state set.

David Holmes

_______________________________________________
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 whentouselockInterruptibly

Dawid Kurzyniec

>>With a lock() you always get the lock? What if the thread is interrupted
>>while it wants to acquire a lock with the lock() method. What is going
>>to happen? With a lockInterruptibly() a InterruptedException is thrown.
>>But what happens with a normal lock() method?
>>    
>>
>
>As Dawid said the normal lock() method will only return once the lock has
>been acquired, and it always returns normally. If you get interrupted while
>trying to acquire it then you remain with your interrupt state set.
>
>David Holmes
>
>  
>
A small clarification: when I wrote my answer, I (and David, I guess)
had in mind ReentrantLock and ReentrantReadWriteLock. For user-defined
locks, the documentation actually allows lock() method to throw
unchecked exception (e.g. as a deadlock-avoidance measure). Also,
theoretically, lock() can throw OutOfMemoryError even from
ReentrantLock.lock (right?) so it is not 100% accurate to say that
lock() can never complete abruptly.

It has nothing to do with interruption, though - the lock() method is
supposed to block *non-interruptibly* if the lock is not immediately
available. I imagine it is possible to write a lock implementation that
would violate this and instead throw an unchecked exception upon
interruption of lock(), but in my understanding of the API, such
implementation would be broken - because the javadoc only allows such
exception to be thrown when an *erroneous* use of the lock is detected.

So, to sum up: for properly written lock classes (ReentrantLock in
particular), lock() is non-interruptible and, for all practical
purposes, cannot complete abruptly, unless really bad things happen from
which you probably should not try to recover.

Regards,
Dawid

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