[concurrency-interest] BoundedPriorityBlockingQueue ?

[David Holmes]

Hi Hanson,

Actually what I said, or meant, was the other way around. :)

If you use a blocking put() then you are accepting that you don't care about
the "priority" ordering of threads trying to submit. No problem, no
complexity and no "madness". :)

If you do care about the order of threads trying to submit then you should
not use put() but use offer() so that you can "deal with it". It is in
trying to "deal with it" that I think the "madness" lies ;-)

So the normal BQ semantics are quite sufficient for the job. No need to
introduce a new kind of semi-blocking queue with similar methods but
different semantics. The user can choose blocking put() with no
blocking-order guarantees; or else non-blocking offer() and figure it out
themselves.

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


  Hi David,

  But didn't you point out the normal blocking BQ put() semantics in a
queue-full situation for a bounded PBQ would lead to madness ?

  If so, why not avoid addressing BQ and create something that might be
useful but not a kind of BQ ?

  Hanson


  On 9/12/06, David Holmes <dcholmes at optusnet.com.au> wrote:
    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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060913/815ca4e3/attachment.html