[concurrency-interest] BoundedPriorityBlockingQueue ?

Hanson Char hanson.char at gmail.com
Tue Sep 12 21:37:46 EDT 2006

Hi David,

Sorry for the confusion.  I guess I am proposing something with sematics
slightly different than the formal BlockingQueue interface, in that the
"put" semantics need to be different in order to avoid the madness.

I guess the named BoundedPriorityBlockingQueue is pretty misleading in such
case, but instead should be something like a BoundedPriorityQueue, for the
lack of a better name, which provides blocking methods only on the
dequeueing side, but non-blocking methods for the enqueueing side.


On 9/12/06, David Holmes <dcholmes at optusnet.com.au> wrote:
>  Hanson,
> 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.
> David
> -----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.
> Hanson
> 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.
> >
> > Cheers,
> >  David
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060912/39a038db/attachment-0001.html 

More information about the Concurrency-interest mailing list