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

[Juan Jose Garcia-Ripoll]

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.

Juanjo

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