[concurrency-interest] Quest for the optimal queue
viktor.klang at gmail.com
Sun May 13 06:19:36 EDT 2012
On Sun, May 13, 2012 at 9:40 AM, Michael Barker <mikeb01 at gmail.com> wrote:
> >> > I'd like to explore alternatives to ConcurrentLinkedQueue, especially
> >> > 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
There's no notification needed. If the consumer is currently active, i.e.
is being executed by a thread, we want handoffs to be as cheap as possible.
> 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.
Disruptor doesn't map to this problem since it uses a dedicated thread for
> 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?
Akka Tech Lead
Typesafe <http://www.typesafe.com/> - The software stack for applications
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest