<br><br><div class="gmail_quote">On Sun, May 13, 2012 at 9:40 AM, Michael Barker <span dir="ltr"><<a href="mailto:mikeb01@gmail.com" target="_blank">mikeb01@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">>> > I'd like to explore alternatives to ConcurrentLinkedQueue, especially to<br>
>> > get<br>
>> > a bit lower latency and perhaps even lower mem usage.<br>
>><br>
>> For which use case are you looking to improve latency; the latency<br>
>> cost on the producing thread or latency for moving the message from<br>
>> the publishing thread to the consuming thread?<br>
><br>
><br>
> The latency between writers and reader. So the latter.<br>
<br>
</div>With most of the experimentation done on the Disruptor, the thing that<br>
has the biggest impact on latency is how you notify the consumer<br>
thread. </blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 I've seen latencies as low as 180ns using<br>
ConcurrentLinkedQueue, but required a full busy spin to get there.<br>
That's compared to a lock/condition wake-up on ABQ of about 32 000ns.<br>
The Disruptor has a number of different "WaitStrategies" based on the<br>
trade off between CPU consumption and latency.<br></blockquote><div><br></div><div>Disruptor doesn't map to this problem since it uses a dedicated thread for the BLP?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
I've been meaning to explore a phased back-off strategy of busy-spin<br>
-> spin with yield -> LockSupport.parkNanos.  Building good back-off<br>
strategy in Java is a bit tricky as LockSupport.parkNanos is not<br>
always predictable and you don't have fine grained access to some of<br>
the OS timer facilities.  The latency of the LockSupport.parkNanos(1L)<br>
tends to be somewhere in the region of 65µs on a reasonably modern<br>
Linux kernel, which is okay, I have seen it run into milliseconds on<br>
some revisions of MS Windows.<br>
<br>
I'd be interested in what your consumer looks like.  You mentioned<br>
having millions of the these queues, I'm assuming that you won't be<br>
able to have millions of Java threads as consumers, so you'd be<br>
consuming from multiple queues in a given thread?<br></blockquote><div><br></div><div><a href="https://github.com/akka/akka/blob/master/akka-actor/src/main/scala/akka/dispatch/Mailbox.scala#L174">https://github.com/akka/akka/blob/master/akka-actor/src/main/scala/akka/dispatch/Mailbox.scala#L174</a></div>
<div><br></div><div>Cheers,</div><div>√</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Mike.<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><span style="border-collapse:separate;color:rgb(0,0,0);font-family:Times;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><span style="font-family:arial;font-size:small"><span style="border-collapse:collapse;font-family:arial,sans-serif;font-size:13px">Viktor Klang<br>
<br>Akka Tech Lead</span><div><font face="arial, sans-serif"><span style="border-collapse:collapse"><a href="http://www.typesafe.com/" target="_blank">Typesafe</a><span> </span>- </span></font><span>The software stack for applications that scale</span><br>
<font face="arial, sans-serif"><span style="border-collapse:collapse"><br></span></font><font face="arial, sans-serif"><span style="border-collapse:collapse">Twitter: @viktorklang</span></font></div></span></span><br>