Re: BoundedPriorityBlockingQueue

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: BoundedPriorityBlockingQueue

David Walend

On Sep 12, 2006, at 11:17 PM, concurrency-interest-
[hidden email] wrote:

> Date: Tue, 12 Sep 2006 23:06:12 -0400
> From: "Tim Peierls" <[hidden email]>
>
> On 9/12/06, Dhanji R. Prasanna <[hidden email]> 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://
somnifugijms.dev.java.net/source/browse/*checkout*/somnifugijms/v3/
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,

Dave

David Walend
[hidden email]


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest