[concurrency-interest] Quest for the optimal queue

Doug Lea dl at cs.oswego.edu
Sat May 12 06:49:21 EDT 2012

On 05/11/12 11:00, √iktor Ҡlang wrote:

> I'd like to explore alternatives to ConcurrentLinkedQueue, especially to get a
> bit lower latency and perhaps even lower mem usage.

LinkedTransferQueue is often a bit faster than ConcurrentLinkedQueue,
so you should give it a try.

> No locks, Unbounded, Single consumer, Multiple producers
> Operations:
> dequeue, enqueue, numberOfMessages, hasMessages

In general, we can do better than CLQ/LTQ only by weakening
some specs, including:

* Relaxing strict FIFO guarantees
* Specializing for a single producer, single consumer, or both.
* Relaxing guarantees about or not supporting blocking
* Not supporting some Collection operations (in particular, as
Martin noted, supporting arbitrary remove(element) forces
very noticeable overhead on unrelated operations.)

There are a number of good algorithms that make some of
these tradeoffs (flat-combining, multi-lane, Lamport etc),
including some used internally (like the fast task queues
used inside ForkJoin). We haven't put any in j.u.c. mainly
because they seem to fall outside of the scope of kinds of
components that should ship with JDK. We ought to consider
developing and releasing some in some other way.


More information about the Concurrency-interest mailing list