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

Benedict Elliott Smith belliottsmith at datastax.com
Wed Feb 5 04:19:30 EST 2014


I'm certainly not wed to the method names. I have a preference to not
require a predicate for the conditional poll, though, as for the near
future this is likely to mean a heap allocation that could otherwise be
avoided.

Another one to consider is a suitably named conditional append (still for
CLQ), although this is more questionably useful. I think a predicate would
be more necessary here, to make it properly useful in the face of
destructive modification to the head of the queue that catches up with the
tail. e.g. I have had a scenario where I wanted to append a new resource to
a queue on the assumption that no other such resources had been appended
since the queue was just iterated, or that the queue is now empty.




On 4 February 2014 17:14, Martin Buchholz <martinrb at google.com> wrote:

> 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/20140205/f3c493a8/attachment.html>


More information about the Concurrency-interest mailing list