[concurrency-interest] PriorityBlockingQueue put() operation
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:
> 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.
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest