[concurrency-interest] BoundedPriorityBlockingQueue ?

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


>something like a BoundedPriorityQueue, for the lack of a better name, which
provides
>which provides blocking methods only on the dequeueing side, but
non-blocking methods
>for the enqueueing side.

That is, the enqueueing side of such "BPQ" has a "put" that can throw
exception, and an "offer" that can return false, iff the queue were full.

Hope I am not causing further confusion.

Hanson

On 9/12/06, Hanson Char <hanson.char at gmail.com> wrote:
>
> 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.
>
>
> Hanson
>
>
> 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/e9ba8f41/attachment.html 


More information about the Concurrency-interest mailing list