[concurrency-interest] BoundedPriorityBlockingQueue ?
hanson.char at gmail.com
Tue Sep 12 21:37:46 EDT 2006
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:
> 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.
> > Cheers,
> > David
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest