[concurrency-interest] is ConcurrentLinkedQueue is truely wait-free?

Pedro Ramalhete pramalhe at gmail.com
Mon Jun 24 17:27:37 EDT 2013

Hi Mudit,
I completely agree with you. According to the the definition of wait-free,
an object or data-structure can only be called wait-free if _all_ of its
methods are wait-free, which is clearly not the case of the
ConcurrentLinkedQueue and, therefore, the documentation should be corrected.

Martin, I believe that some of the methods in the CLQ are technically
wait-free, but in case I'm wrong, then it's even a stronger reason to
change the documentation ;)
Moreover, I agree with you that the difference between a wait-free queue
and a lock-free queue is mostly academic, but only for queues, not for
other data structures.

On Wed, Jun 19, 2013 at 6:45 PM, Martin Buchholz <martinrb at google.com>wrote:

> On Wed, Jun 19, 2013 at 7:38 AM, Oleksandr Otenko <
> oleksandr.otenko at oracle.com> wrote:
>> If the queue is blocking, how can it be wait-free.
>> If the queue is non-blocking, there must be a non-blocking alternative to
>> (possibly even wait-free) failure to poll() or offer().
>> I am not sure what a certain *-freedom gives you in this context.
> If you're saying it doesn't matter much to the user whether poll() is
> wait-free or lock-free, then I agree.  This is mostly of academic interest.
>  Especially when java thread priorities generally don't work, and there's
> no risk of priority inversion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130624/1036a36c/attachment.html>

More information about the Concurrency-interest mailing list