[concurrency-interest] Quest for the optimal queue

√iktor Ҡlang 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
> 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.


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
the BLP?


>
> 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?
>

https://github.com/akka/akka/blob/master/akka-actor/src/main/scala/akka/dispatch/Mailbox.scala#L174

Cheers,
√


>
> Mike.
>



-- 
Viktor Klang

Akka Tech Lead
Typesafe <http://www.typesafe.com/> - The software stack for applications
that scale

Twitter: @viktorklang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120513/80a7de35/attachment.html>


More information about the Concurrency-interest mailing list