[concurrency-interest] BoundedPriorityBlockingQueue ?

Hanson Char hanson.char at gmail.com
Tue Sep 12 21:49:26 EDT 2006


Hi David,

>If the user were concerned that blocking puts weren't ordered correctly
>then the user should just use non-blocking offer() and "deal with it"
>when it returns false.

But the "problem" is PriorityBlockingQueue as at now
1) never returns false when offer() is invoked; and
2) unbounded

In other words, the user never has a chance to deal with the queue-full
situation if PBQ is used, unless he has something like the
"BoundedPriorityQueue" beast I suggest.

Hanson

On 9/12/06, David Holmes <dcholmes at optusnet.com.au> wrote:
>
>  Hanson,
>
> I don't see why we need different "put" semantics. If the user were
> concerned that blocking puts weren't ordered correctly then the user should
> just use non-blocking offer() and "deal with it" when it returns false. If
> you slipped such a thing into a ThreadPoolExecutor today it would just work,
> and the RejectedExecutionHandler would be the way the application could
> "deal with it".
>
> Cheers,
> David
>
> -----Original Message-----
> *From:* Hanson Char [mailto:hanson.char at gmail.com]
> *Sent:* Wednesday, 13 September 2006 11:38 AM
> *To:* dholmes at ieee.org
> *Cc:* concurrency-interest
> *Subject:* Re: [concurrency-interest] BoundedPriorityBlockingQueue ?
>
> 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/061ba82d/attachment-0001.html 


More information about the Concurrency-interest mailing list