[concurrency-interest] BoundedPriorityBlockingQueue ?

David Holmes dcholmes at optusnet.com.au
Tue Sep 12 21:42:22 EDT 2006


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/20060913/6c569216/attachment.html 


More information about the Concurrency-interest mailing list