[concurrency-interest] PriorityBlockingQueue put() operation
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.
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...
More information about the Concurrency-interest