Hi Juan,<br><br>is this change supposed to work on windows/mingw?<br><br>I just tried compiling latest ECL and i got ecl_min compile hangs spinning 100% cpu indefinitely while trying to do the following.<br><br>if [ -f CROSS-COMPILER ]; then \<br>

                ./CROSS-COMPILER compile; \<br>        else \<br>                ECLDIR=`pwd`/ ./ecl_min.exe compile; \<br>        fi<br><br>Regards,<br>Marko Kocić<br><br><div class="gmail_quote">On Sun, Mar 18, 2012 at 5:33 PM, Juan Jose Garcia-Ripoll <span dir="ltr"><<a href="mailto:juanjose.garciaripoll@googlemail.com">juanjose.garciaripoll@googlemail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<div>

<br></div><div>The code has been tested using Matthew Mondor's web server (<a href="http://article.gmane.org/gmane.lisp.ecl.general/8965" target="_blank">http://article.gmane.org/gmane.lisp.ecl.general/8965</a>) 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.</div>



<div><br></div><div>The current philosophy is as follows:</div><div>* The lock is a word-sized field in a structure, atomically updated by the locking thread.</div><div>* The no-wait locking amounts to trying to reset the field atomically (using libatomics), and returning NIL if the field is already set.</div>



<div>* The wait mechanism consits on three phases</div><div>++ try to acquire the lock once</div><div>++ enter ecl_wait_on() which will</div><div>+++ first perform a brief spin lock</div><div>+++ then enter a look with increasing wait times</div>



<div>* 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().</div><div><br></div><div>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.</div>



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



<div><br></div><div>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.</div><div><br></div><div>Juanjo</div><span class="HOEnZb"><font color="#888888"><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>
</font></span><br>------------------------------------------------------------------------------<br>
This SF email is sponsosred by:<br>
Try Windows Azure free for 90 days Click Here<br>
<a href="http://p.sf.net/sfu/sfd2d-msazure" target="_blank">http://p.sf.net/sfu/sfd2d-msazure</a><br>_______________________________________________<br>
Ecls-list mailing list<br>
<a href="mailto:Ecls-list@lists.sourceforge.net">Ecls-list@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/ecls-list" target="_blank">https://lists.sourceforge.net/lists/listinfo/ecls-list</a><br>
<br></blockquote></div><br>