[concurrency-interest] BoundedPriorityBlockingQueue ?

David Holmes dcholmes at optusnet.com.au
Tue Sep 12 21:09:01 EDT 2006

Sorry Hanson, I know you weren't the originator here.

What I failed to say, in response to your comments regarding return values
or exceptions is that BPBQ already has the necessary API's - there are
blocking and non-blocking forms of "put" and "take" so the application can
already choose to use non-blocking forms if they want to deal with a full

  -----Original Message-----
  From: Hanson Char [mailto:hanson.char at gmail.com]
  Sent: Wednesday, 13 September 2006 10:59 AM
  To: dholmes at ieee.org
  Cc: concurrency-interest
  Subject: Re: [concurrency-interest] BoundedPriorityBlockingQueue ?

  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.


  On 9/12/06, David Holmes <dcholmes at optusnet.com.au> wrote:

    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.

    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 ?


      On 9/12/06, Brian Goetz <brian at quiotix.com> wrote:
        The tricky part is if you want to guarantee that the thread offering
        element of highest priority is first to be unblocked.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060913/19f118ba/attachment-0001.html 

More information about the Concurrency-interest mailing list