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

Martin Buchholz martinrb at google.com
Mon Dec 1 14:47:01 EST 2014


It seems unlikely that you would be the first person to find a
missing-interrupt bug in either ABQ or AQS or park.  From your
description you are not making 100% sure that the thread is already in
take when the interrupt is delivered.  Maybe it got swallowed before?

Have you tried different jdk versions?

On Mon, Dec 1, 2014 at 11:08 AM, Charles Oliver Nutter
<headius at headius.com> wrote:
> 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
> [0x000000011a951000]
>
>    java.lang.Thread.State: WAITING (parking)
>
> at sun.misc.Unsafe.park(Native Method)
>
> - parking to wait for  <0x00000007b6c7c890> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>
> 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
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest


More information about the Concurrency-interest mailing list