[concurrency-interest] BoundedPriorityBlockingQueue ?

David Holmes dcholmes at optusnet.com.au
Tue Sep 12 21:29:48 EDT 2006


I'm confused: BoundedPriorityBlockingQueue is-a BlockingQueue and so we
would have the normal semantics for BlockingQueue methods on a bounded
implementation. So offer() would return false, and put() would block, if the
queue were full.

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

  Hi David,

  I suppose you mean PBQ (as opposed to BPBQ which doesn't yet exist)
already has the necessary API.

  True.  However, although there are both the blocking "put" and
non-blocking "offer" methods in PBQ, the blocking "put" as at now never
blocks and the non-blocking "offer" always return true (ie succeed) because
PBQ is unbounded!

  What I am suggesting is that if we implemented something like a Bounded
PBQ (BPBQ), then we could "meaningfully" make "offer" return false when the
queue is full (and true otherwise).  Since the return type of "put" is void,
we can throw something like a QueueFullException when the queue is full.

  "meaningful" or not, of course, depends whether such BPBQ is considered
useful, which I don't know.


  On 9/12/06, David Holmes <dcholmes at optusnet.com.au> wrote:
    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 queue.


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

More information about the Concurrency-interest mailing list