[concurrency-interest] PooledExector -- not clear on execute() + waitWhenBlocked()

Doug Lea dl@cs.oswego.edu
Wed, 14 Jan 2004 23:44:32 -0500

Elias Ross wrote:
> I've been trying to fix a bug in JBoss's JMS implementation.  I am 
> assuming during the Runnable.run() method an unchecked exception gets
>  thrown or the Thread.interrupt() is called and the pool eventually 
> becomes smaller and unusable.  Looking at the PooledExector class, it
>  isn't clear why this would be the case.  There are no obvious
> JavaDoc statements that explain this sort of thing can happen.

This is a known documentation lapse in dl.u.c that I need to address.
WaitWhenBlock policy is fairly fragile in dl.u.c.PooledExecutor: You
need to configure the pool so that is impossible for there to be zero
worker threads; otherwise you can expose yourself to races where
blocked task producers resume but there are no threads.

More generally, WaitWhenBlocked is rarely a good policy -- it invites
various lockups and deadlocks unless you are very careful. CallerRuns
is much better wrt concurrency control. So we do not even build
WaitWhenBlocked in to
ThreadPoolExecutor; you'd have to go to the trouble of defining it
yourself in those infrequent cases where you do need it. (I suspect not
ever inside JBoss.)