[Ecls-list] Latest changes

[Marko Kocić]

Hi Juan,

is this change supposed to work on windows/mingw?

I just tried compiling latest ECL and i got ecl_min compile hangs spinning
100% cpu indefinitely while trying to do the following.

if [ -f CROSS-COMPILER ]; then \
                ./CROSS-COMPILER compile; \
        else \
                ECLDIR=`pwd`/ ./ecl_min.exe compile; \
        fi

Regards,
Marko Kocić

On Sun, Mar 18, 2012 at 5:33 PM, Juan Jose Garcia-Ripoll <
juanjose.garciaripoll at googlemail.com> wrote:

> I have uploaded a set of changes that covers various things, including
> some recent bug reports and the implementation of locks and condition
> variables. I will focus on the locks here.
>
> The code has been tested using Matthew Mondor's web server (
> http://article.gmane.org/gmane.lisp.ecl.general/8965) with a varying
> number of connections and threads. I have witnessed some glitches but only
> when recompiling and using a new executable. Will continue testing, though.
>
> The current philosophy is as follows:
> * The lock is a word-sized field in a structure, atomically updated by the
> locking thread.
> * The no-wait locking amounts to trying to reset the field atomically
> (using libatomics), and returning NIL if the field is already set.
> * The wait mechanism consits on three phases
> ++ try to acquire the lock once
> ++ enter ecl_wait_on() which will
> +++ first perform a brief spin lock
> +++ then enter a look with increasing wait times
> * The unlocking routine is now designed to awake at least one thread. This
> is done by issuing an interrupt that will disrupt the waiting loop from
> ecl_wait_on().
>
> As discussed earlier, the advantage of this user space implementation is
> that we have full control of the status of the lock even when interrupts
> occur.
>
> Time-wise, it seems to be slower than the pthreads implementation,
> reaching 400 connections / second or 2.5 ms / connection in Matthew's
> tests, vs. 1.5 ms / connection for pthreads (ECL 12.1.1). On the other
> hand, I have not seen any segfaults and it still puzzles me the difference:
> using a profiler I do not see any more time being spent in the waiting loop
> (it is 0.4% of the total time)
>
> The code is not yet extremely mature and I believe it has to be possible
> to improve the speed or at least learn how to do a more efficient wait loop.
>
> Juanjo
>
> --
> Instituto de Física Fundamental, CSIC
> c/ Serrano, 113b, Madrid 28006 (Spain)
> http://juanjose.garciaripoll.googlepages.com
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Ecls-list mailing list
> Ecls-list at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ecls-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20120319/a625e2f0/attachment.html>