[concurrency-interest] Quest for the optimal queue

Michael Barker mikeb01 at gmail.com
Sun May 13 03:40:17 EDT 2012

>> > I'd like to explore alternatives to ConcurrentLinkedQueue, especially to
>> > get
>> > a bit lower latency and perhaps even lower mem usage.
>> For which use case are you looking to improve latency; the latency
>> cost on the producing thread or latency for moving the message from
>> the publishing thread to the consuming thread?
> The latency between writers and reader. So the latter.

With most of the experimentation done on the Disruptor, the thing that
has the biggest impact on latency is how you notify the consumer
thread.  I've seen latencies as low as 180ns using
ConcurrentLinkedQueue, but required a full busy spin to get there.
That's compared to a lock/condition wake-up on ABQ of about 32 000ns.
The Disruptor has a number of different "WaitStrategies" based on the
trade off between CPU consumption and latency.

I've been meaning to explore a phased back-off strategy of busy-spin
-> spin with yield -> LockSupport.parkNanos.  Building good back-off
strategy in Java is a bit tricky as LockSupport.parkNanos is not
always predictable and you don't have fine grained access to some of
the OS timer facilities.  The latency of the LockSupport.parkNanos(1L)
tends to be somewhere in the region of 65µs on a reasonably modern
Linux kernel, which is okay, I have seen it run into milliseconds on
some revisions of MS Windows.

I'd be interested in what your consumer looks like.  You mentioned
having millions of the these queues, I'm assuming that you won't be
able to have millions of Java threads as consumers, so you'd be
consuming from multiple queues in a given thread?


More information about the Concurrency-interest mailing list