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

Charles Oliver Nutter headius at headius.com
Mon Dec 1 14:50:54 EST 2014


I'm working to narrow that down now. You're right...I don't expect to
have found a bug, but I'm having trouble explaining the behavior I'm
seeing.

Just to clarify the key point, though: LockSupport.park should be 100%
wakeable using Thread#interrupt, yes? There's no situation where a
thread in park would *not* be expected to wake up in response to
Thread#interrupt?

- Charlie

On Mon, Dec 1, 2014 at 1:47 PM, Martin Buchholz <martinrb at google.com> wrote:
> 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