[concurrency-interest] Propagation of signals to non-interrupted thread

Martin Buchholz martinrb at google.com
Thu Nov 10 09:06:37 EST 2011


These classes are designed to work with JDK6 as well as JDK7.

AbstractQueuedSynchronizer has been written so that interrupts can never
cause signals to be lost.  If this were not the case, there would be many
more places than just in ArrayBlockingQueue where special handling of
interrupts would be required (and getting concurrent classes right is
already hard enough).  Implementation of ABQ has merely been simplified to
rely on AQS's de-facto guarantee.

This ought to be better documented.

I would like to see the classes in j.u.c.locks document more guarantees
than they currently do.
For example, I'd like to see this guarantee:

diff -u -r1.96 ReentrantLock.java
--- main/java/util/concurrent/locks/ReentrantLock.java 9 Jun 2011 07:48:44
-0000 1.96
+++ main/java/util/concurrent/locks/ReentrantLock.java 10 Nov 2011 14:00:08
-0000
@@ -467,6 +467,9 @@
      * but for <em>fair</em> locks favors those threads that have been
      * waiting the longest.
      *
+     * <li>None of the condition {@linkplain Condition#await() waiting}
+     * methods ever return due to a "<em>spurious wakeup</em>".
+     *
      * </ul>
      *
      * @return the Condition object

Martin

On Thu, Nov 10, 2011 at 05:15, Dr Heinz M. Kabutz
<heinz at javaspecialists.eu>wrote:

> In Java 6, the ArrayBlockingQueue used this construct for the take()
> method:
>
>   public E take() throws InterruptedException {
>       final ReentrantLock lock = this.lock;
>       lock.lockInterruptibly();
>       try {
>           try {
>               while (count == 0)
>                   notEmpty.await();
>           } catch (InterruptedException ie) {
>               notEmpty.signal(); // propagate to non-interrupted thread
>               throw ie;
>           }
>           E x = extract();
>           return x;
>       } finally {
>           lock.unlock();
>       }
>   }
>
> In other words, it would /always/ send a signal on interrupt, even if it
> had not received one.
>
> In Java 7, this was taken away, so we now have:
>
>   public E take() throws InterruptedException {
>       final ReentrantLock lock = this.lock;
>       lock.lockInterruptibly();
>       try {
>           while (count == 0)
>               notEmpty.await();
>           return extract();
>       } finally {
>           lock.unlock();
>       }
>   }
>
> However, I could not find substantial differences between the await()
> methods of Java 6 and 7.  Does this mean that propagating of the signal was
> not necessary in Java 6 either?  According to Doug Lea's book section
> 3.2.4.2, it is necessary with wait/notify to propagate the signal if you
> get interrupted.  However, it looks like Condition.await() is coded to
> cater for this eventuality anyway.
>
> Regards
>
> Heinz
> --
> Dr Heinz M. Kabutz (PhD CompSci)
> Author of "The Java(tm) Specialists' Newsletter"
> Sun Java Champion
> IEEE Certified Software Development Professional
> http://www.javaspecialists.eu
> Tel: +30 69 72 850 460
> Skype: kabutz
> ______________________________**_________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.**oswego.edu <Concurrency-interest at cs.oswego.edu>
> http://cs.oswego.edu/mailman/**listinfo/concurrency-interest<http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20111110/694b2604/attachment-0001.html>


More information about the Concurrency-interest mailing list