[concurrency-interest] ConcurrentLinkedQueue CAS-like poll/iterator remove
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:
> 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.
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest