[concurrency-interest] PriorityBlockingQueue put() operation

David Holmes davidcholmes at aapt.net.au
Sat Nov 7 18:12:33 EST 2009

The term non-blocking here (BlockingQueue.put) is being used in a different
sense to that of the non-blocking/wait-free/lock-free algorithms. It is an
unfortunate terminology clash but the lock-free/wait-free/non-blocking
terminology is only considering mutual-exclusion/atomicity related blocking
(for want of a better term).

In general any method that has to wait for a state-related condition to hold
(space in buffer, item in buffer, data on socket, time-X-has-elapsed) is a
blocking method, and any method that doesn't have to wait is a non-blocking
method. And this is independent of whether locking is also involved.

  -----Original Message-----
  From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Joe Bowbeer
  Sent: Sunday, 8 November 2009 9:01 AM
  To: concurrency-interest at cs.oswego.edu
  Subject: Re: [concurrency-interest] PriorityBlockingQueue put() operation

  On Sat, Nov 7, 2009 at 12:01 PM, Michael Spiegel wrote:


    I apologize if this question has been answered before of if the answer
    is trivially obvious.  The documentation for
    java.util.concurrent.PriorityBlockingQueue states that the put(E e)
    method will never block, and such claims are not made about the add(E
    e) method.  The method bodies for both methods are identical, ignoring
    the fact that one method returns boolean and the other doesn't return
    a value.  The methods body is an invocation to the offer(E e) method.
    I believe that offer() is a blocking method, since it locks the
    ReentrantLock around the data structure.  So is put() a blocking
    method? I must be missing something obvious.


  Wikipedia currently makes this distinction:

    "In computer science, non-blocking synchronization ensures that threads
competing for a shared resource do not have their execution indefinitely
postponed by mutual exclusion. A non-blocking algorithm is lock-free if
there is guaranteed system-wide progress; wait-free if there is also
guaranteed per-thread progress."


  So non-blocking < lock-free < wait-free ?

  Consider old (blocking) java.io and the newer asynchronous java.nio.  They
both use locks of some sort, but nio is non-blocking.

  Object.wait is typically a good indicator of  blocking.  (As is throws


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20091108/e06cdd2e/attachment.html>

More information about the Concurrency-interest mailing list