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

Doug Lea dl at cs.oswego.edu
Wed Feb 5 08:47:37 EST 2014

On 02/04/2014 11:48 AM, Benedict Elliott Smith wrote:
> This may be a bit on the late side for inclusion in JDK8,

No chance. JKD8 is completely frozen except for show-stopper bugs.

>  but I noticed that
> ConcurrentLinkedQueue has moved to a non-blocking algorithm,

It has always been non-blocking. Maybe you are thinking of a different Queue?

> However, it would be particularly nice to get a pollIfHead(item) method, which

Yes, we initially contemplated a takeIfFirst(Object x) method. Sorry
that I have no recollection of why this never made it into Queue API.
It would be nearly impossible to add it to interface since there is
no reasonable default implementation, but easy to add to CLQ and some
others. I cannot think of a reason not to do this for JDK9.

> possibly an extension of
> Iterator that supports atomicRemove() (returning success/failure) or similar.

I agree that it would have been nice for Iterator.remove to return a
boolean (like Collection remove does). But considering that nearly
all Queue iterators are intrinsically slow anyway (processing
the internal items of a concurrent queue is an unnatural act),
the argument for not just forcing people needing this to use
queue.remove(x) is not all that compelling given that we would
need to define a special Iterator subinterface and class
just to expose this.


More information about the Concurrency-interest mailing list