<div class="gmail_quote">On Fri, Feb 17, 2012 at 8:53 AM, 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">

I see that this is similar to an adaptive spinlock, that'll spin, and<br>
then sleep if the lock cannot be obtained when in blocking mode.<br>
However, it naturally cannot magically awaken immediately when a lock<br>
is freed, but wait until the sleep operation returned, so it<br>
busy-sleeps.<br></blockquote><div><br></div><div>It is the approach that SBCL follows. I considered the possibility of doing something more fancy, but there are some problems associated to it: a waiting list will cons; it has also associated some synchronization problems; awaking a thread implies an interruptible wait mechanism or a wait with a timeout -- tricky in Windows, possible with nanosleep() + interrupts, very difficult otherwise.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Unfortunately my testing was quite summary as I couldn't build SLIME<br>
anymore under the new ECL, it errors about the lack of condition<br>
variables.<br></blockquote><div><br></div><div>That is the second step. Condition variables need a wait queue, which as I said above, these mutexes do not have. We also cannot reuse pthreads' conditions variables because they rely on pthreads' mutexes.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As for stability testing, I could stress test the HTTPd using various<br>
ab runs, but still experienced some instability when doing 5000+<br>
connections runs at 16+ concurrency (ab -c16 -n5000).  A stack overflow<br>
error eventually was produced at the REPL and I could not recover<br>
gracefully without restarting ECL.  The previous runs using -n1000 were<br>
successful, but I didn't really run more than a douzen so far.</blockquote></div><br clear="all"><div>Is there a way I can reproduce those problems here? I am puzzled by the stack overflow. Why would it happen? I definitely need to gdb that.</div>

<div><br></div><div>Juanjo</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>