[concurrency-interest] PriorityBlockingQueue put() operation

Martin Buchholz martinrb at google.com
Sat Nov 7 15:48:48 EST 2009

There is a terminology problem here.
Since locks are used, none of the methods are "non-blocking"
in the currently popular technical sense.

I don't know how best to describe an algorithm that
will need to acquire a lock, but once it does so,
will be able to proceed immediately, and not have to
wait indefinitely for some other thread to take action.
The word "wait-free" is taken.


On Sat, Nov 7, 2009 at 12:01, Michael Spiegel
<michael.m.spiegel at gmail.com>wrote:

> Hi,
> 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.
> Thanks!
> --Michael
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20091107/682a44c8/attachment.html>

More information about the Concurrency-interest mailing list