[concurrency-interest] BoundedPriorityBlockingQueue ?

rbalamohan rbalamohan at sonoasystems.com
Tue Sep 12 22:55:26 EDT 2006

I agree with David on this. However, in certain cases like
ThreadPoolExecutor as I mentioned earlier, having BPBQ might be useful.

The way threadPoolExecutor handles execute(Runnable command) is that,
"if the task can't be submitted due to shutdown or because the capacity
has been reached, the task is handled by RejectedExecutionHandler".

Also, we pass a BlockingQueue (basically the workerQueue) in the
ThreadPoolExecutor constructor. In this case, we can pass a BPBQ and
have the priorities assigned to the tasks being submitted. Also, when
the queue is full, this situation can be handled by the


On Tue, 2006-09-12 at 17:58 -0700, Hanson Char wrote:

> Hi David,
> Completely agree.  That's why I am proposing if there was such thing
> as a Bounded PBQ, the BPBQ per se wouldn't want to deal with the
> madness when the queue is full, but simply pass the onus to the user
> (via the return value of put or via exception), and let the user
> decides what to do about it. 
> I don't know, however, if such behavior and such BPBQ would be useful
> at all, and hence my question to the originator, rbalamohan.
> Hanson
> On 9/12/06, David Holmes <dcholmes at optusnet.com.au> wrote:
>         Hanson,
>         The basic issue here is that you use a PriorityBlockingQueue
>         to prioritize tasks, under the expectation that the queue will
>         actually fill to some extent, so the relative importance of
>         tasks is, well, important. You then place a bound on that
>         queue and the result is you now have a second (unbounded)
>         queue of threads trying to submit prioritized tasks. So then
>         you wonder if those threads should be unblocked in order of
>         priority of their tasks? But that way madness lies ... this
>         isn't real-time priority preemptive systems programming. If
>         you really think that the threads need to be queued in
>         priority order too then make your priority queue bigger. If
>         you size things out and you really must bound the size of the
>         queue and you really expect lots of threads to block waiting
>         to put to the queue and you really think the priority of the
>         tasks those threads are submitting need to be accounted for,
>         then you have a problem. Basically you would have to have each
>         submitter check if its task is more important than the lowest
>         priority one in the queue and try to swap the new task for the
>         old one; and then keep retrying to submit the swapped out
>         task. This is really, really messy. Throw in priority-aging to
>         avoid starvation and things get even worse. :)
>         Sometimes there is no complete solution - you have to define
>         the boundaries where you take into account things like
>         priority. Sometimes the answer is to have a completely
>         different mechanism for things that are really important (most
>         queueing systems (banks, airlines etc) don't use priority
>         ordered queues, they use different queues for different
>         "priorities" or allow bypassing of the queue altogether.
>         Just my 2c.
>         Cheers,
>         David Holmes
>                 -----Original Message-----
>                 From: concurrency-interest-bounces at cs.oswego.edu
>                 [mailto:concurrency-interest-bounces at cs.oswego.edu]On
>                 Behalf Of Hanson Char
>                 Sent: Wednesday, 13 September 2006 6:20 AM
>                 To: rbalamohan at sonoasystems.com
>                 Cc: Brian Goetz; concurrency-interest; Kasper Nielsen
>                 Subject: Re: [concurrency-interest]
>                 BoundedPriorityBlockingQueue ?
>                 I see blocking on put on a
>                 BoundedPriorityBlockingQueue is not such a good
>                 idea.  
>                 How about making the put method return a false boolean
>                 value upon queue full, or alternatively throwing
>                 something like a QueueFullException ? 
>                 Would this be useful/sensible ?
>                 Hanson
>                 On 9/12/06, Brian Goetz <brian at quiotix.com> wrote: 
>                         The tricky part is if you want to guarantee
>                         that the thread offering the
>                         element of highest priority is first to be
>                         unblocked. 
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060913/7d5d530f/attachment.html 

More information about the Concurrency-interest mailing list