[concurrency-interest] BoundedPriorityBlockingQueue ?

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


Hanson,

We are miscommunicating. If we created a bounded PBQ then it need only have
normal BQ semantics. With such a bounded PBQ the user would use put() or
offer() based on their own needs regarding what should happen when the queue
is full.

Cheers,
David
  -----Original Message-----
  From: Hanson Char [mailto:hanson.char at gmail.com]
  Sent: Wednesday, 13 September 2006 11:49 AM
  To: dholmes at ieee.org
  Cc: concurrency-interest
  Subject: Re: [concurrency-interest] BoundedPriorityBlockingQueue ?


  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/20060913/152cecab/attachment.html 


More information about the Concurrency-interest mailing list