<div class="gmail_quote">On Sun, Mar 18, 2012 at 11:19 PM, Matthew Mondor <span dir="ltr"><<a href="mailto:mm_lists@pulsar-zone.net">mm_lists@pulsar-zone.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div id=":1za">When I had done the initial benchmarking, what seemed to be the problem<br>
was that a thread waiting for a lock wouldn't wake up as fast as<br>
previously when the lock became available.  The wakeup mechanism<br>
probably helps but it's plausible that threads waiting on a lock still<br>
don't wake up as fast as with the pthreads implementation, which would<br>
likely explain the difference.<br></div></blockquote></div><br>I have changed the implementation using now a FIFO queue. The times seem to improve a lot for short tests, going up to 731 connections / s or 1.4 ms / connection on average. For longer tests it degrades a bit and goes up to 1.9 ms, which I attribute to consing.<div>

<br></div><div>The queue is based on a spinlock and I believe the FIFO character plus the fact that the waiters spinlock with waiting times that are at most 0.1s should provide enough of a balance not to make it too unfair. But to be honest, I have not done any research on how to make this theoretically sound.</div>

<div><br></div><div>As potential improvements I see:</div><div>* Changing the queue so that it does not cons (perhaps with a "next" field in the process object itself)</div><div>* The queue has the format multiple produces - one consumer, meaning that it can be implemented without a lock (just CAS).</div>

<div><br></div><div>Juanjo</div><div><div><br></div>-- <br>Instituto de Física Fundamental, CSIC<br>c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://juanjose.garciaripoll.googlepages.com" target="_blank">http://juanjose.garciaripoll.googlepages.com</a><br>


</div>