[concurrency-interest] BoundedPriorityBlockingQueue

David Walend david at walend.net
Wed Sep 13 08:34:30 EDT 2006

On Sep 12, 2006, at 11:17 PM, concurrency-interest- 
request at cs.oswego.edu wrote:

> Date: Tue, 12 Sep 2006 23:06:12 -0400
> From: "Tim Peierls" <tim at peierls.net>
> On 9/12/06, Dhanji R. Prasanna <dhanji at gmail.com> wrote:
>> If there are mission critical differences I certainly would not  
>> trust them
>> to the same threadpool.
> Building that lack of trust into task submission code might also be a
> mistake.
> Maybe this is obvious to all, but here's a reminder: Sometimes the  
> best
> strategy is not to settle definitively on a particular strategy but to
> encapsulate the execution policy within an Executor or  
> ExecutorService. That
> way, by changing the concrete type of an Executor and without  
> affecting the
> client code, you can change your mind at deploy time about whether  
> to use
> separate thread pools.
> Then you can measure the effectiveness of different strategies in  
> practice
> instead of trying to reason in the abstract about which works better.

Well said. I found that developers preferred a PriorityBlockingQueue  
with a custom Comparator to a FIFO queue ( https:// 
source/somnifugi/net/walend/somnifugi/juc/PriorityChannel.java ).  
MessageComparator first differentiates by priority, then by age  
(oldest first), then by something arbitrary but predictable. The  
developers prefer it because of the predictability.

In practice, we get around needing to bound the size by answering,  
"How will the system respond if the queue gets too big?"  
PriorityBlockingQueue has a size() method, so we can monitor it. When  
it gets too big or is growing too fast, we start more consumers or  
throttle back the less important producers or redesign to make the  
consumers more efficient. Throttling back the producers via blocking  
is a heavy handed option; it might save us running out of memory but  
would mean something else is broken.

Hope that helps,


David Walend
david at walend.net

More information about the Concurrency-interest mailing list