[Ecls-list] Slightly disruptive change (in threads)

Juan Jose Garcia-Ripoll juanjose.garciaripoll at googlemail.com
Fri Feb 17 09:31:12 UTC 2012

On Fri, Feb 17, 2012 at 8:53 AM, Matthew Mondor <mm_lists at pulsar-zone.net>wrote:

> I see that this is similar to an adaptive spinlock, that'll spin, and
> then sleep if the lock cannot be obtained when in blocking mode.
> However, it naturally cannot magically awaken immediately when a lock
> is freed, but wait until the sleep operation returned, so it
> busy-sleeps.

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.

> Unfortunately my testing was quite summary as I couldn't build SLIME
> anymore under the new ECL, it errors about the lack of condition
> variables.

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.

> As for stability testing, I could stress test the HTTPd using various
> ab runs, but still experienced some instability when doing 5000+
> connections runs at 16+ concurrency (ab -c16 -n5000).  A stack overflow
> error eventually was produced at the REPL and I could not recover
> gracefully without restarting ECL.  The previous runs using -n1000 were
> successful, but I didn't really run more than a douzen so far.

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.


Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20120217/09fa70cb/attachment.html>

More information about the ecl-devel mailing list