[concurrency-interest] ArrayBlockingQueue (and possibly others) not waking on interrupt?

Charles Oliver Nutter headius at headius.com
Mon Dec 1 14:08:46 EST 2014

To confirm I'm actually sending the interrupt, I added logging output
to my test. The log line is immediately before a call to
Thread#interrupt. I do not understand how the thread could still be
parked (about five seconds later when I triggered the thread dump):

interrupting in take: Thread[Ruby-0-Thread-49: blah.rb:1,5,main]

^\2014-12-01 13:00:57

Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.40-b14 mixed mode):

"Ruby-0-Thread-49: blah.rb:1" #60 daemon prio=5 os_prio=31
tid=0x00007fd43b74f000 nid=0x5bbf waiting on condition

   java.lang.Thread.State: WAITING (parking)

at sun.misc.Unsafe.park(Native Method)

- parking to wait for  <0x00000007b6c7c890> (a

at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)

at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)

at java.util.concurrent.ArrayBlockingQueue.take(ArrayBlockingQueue.java:403)

- Charlie

On Mon, Dec 1, 2014 at 12:50 PM, Charles Oliver Nutter
<headius at headius.com> wrote:
> I have been trying to find a bug in JRuby that involves a queue wait
> hanging when it should be successfully interrupted. I'm starting to
> believe it's a bug in either ArrayBlockingQueue or classes downstream
> from #take (e.g. LockSupport). I have so far been unable to reproduce
> with simple Java code because it requires a lot of overhead. It fails
> once out of 1000 loops in Ruby code.
> The scenario is that thread A is waiting on an ArrayBlockingQueue of
> size 1, and thread B comes along and calls Thread#interrupt on it.
> Most of the time this succeeds, but when it fails I see thread A
> happily sitting in LockSupport.park logic even though it should have
> been woken up.
> I can only think of a few possible scenarios for this:
> * LockSupport.park is not receiving the thread interrupt, or otherwise
> does not (can not?) atomically check it before descheduling the
> thread.
> * The interrupt is getting improperly cleared by something in the
> ArrayBlockingQueue or downstream before it gets into the park call.
> * I'm doing this wrong.
> Help?
> - Charlie

More information about the Concurrency-interest mailing list