[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
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
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
>> 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
>>> * 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.
>>> - Charlie
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
More information about the Concurrency-interest