[concurrency-interest] ConcurrentLinkedQueue CAS-like poll/iterator remove

Martin Buchholz martinrb at google.com
Tue Feb 4 12:14:18 EST 2014

These suggestions seem reasonable to me, but concurrent collections have
conservative api evolution and are focused on implementing the existing
Collection interfaces.  Which were often designed for a non-concurrent
world.  A concurrent iterator that supported atomic removal seems better
than the traditional void remove() method.  I would name it tryRemove
rather than atomicRemove.  And instead of E pollIfHead(item) I'm thinking E
poll(predicate).  ConcurrentLinkedDeque can get the same treatment.

What does Doug think?

On Tue, Feb 4, 2014 at 8:48 AM, Benedict Elliott Smith <
belliottsmith at datastax.com> wrote:

> Hi,
> This may be a bit on the late side for inclusion in JDK8, but I noticed
> that ConcurrentLinkedQueue has moved to a non-blocking algorithm, which is
> great. It means I may be able to dispose of my own in some places.
> However, it would be particularly nice to get a pollIfHead(item) method,
> which behaves like a depth-1 limited remove(item), and possibly an
> extension of Iterator that supports atomicRemove() (returning
> success/failure) or similar.
> Both of these operations have been essential in some algorithms I've
> implemented recently, although I may be fairly alone in that. However,
> they're both very easy to add to the new CLQ implementation.
> I'd be happy to submit a patch, although other than deciding the name of
> any new interface for atomic interator removal, it's pretty trivial.
> Thoughts?
> _______________________________________________
> 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/20140204/a31198ad/attachment.html>

More information about the Concurrency-interest mailing list