[concurrency-interest] BoundedPriorityBlockingQueue ?

David Holmes dcholmes at optusnet.com.au
Tue Sep 12 22:10:29 EDT 2006


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 


More information about the Concurrency-interest mailing list