[concurrency-interest] ArrayBlockingQueue (and possibly others) not waking on interrupt?
martinrb at google.com
Mon Dec 1 14:29:35 EST 2014
Doesn't seem like a known problem...
You could try varying the parameters trying to track down the root cause.
- make the ABQ capacity > 1 ? capacity 1 is unusual.
- use another blocking queue implementation?
- you could instrument your code to make 100% sure that the queue is
currently empty and the taker is currently blocked by checking its
Thread.State before sending the interrupt
Us non-rubyists are likely to be looking for a 100% java repro recipe.
of course, if you check for empty, then send an interrupt, there is a
race where the queue may receive an element in between.
On Mon, Dec 1, 2014 at 10:50 AM, 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