<div class="gmail_quote">On Thu, Feb 9, 2012 at 11:10 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">

So I again tested my simplified mutex.d implementation and<br>
interestingly, stability improved this time.  So what I did is to merge<br>
it along with the Windows support, which still uses the old<br>
holder/counter dance.  The new POSIX implementation avoids this and<br>
simply relies on the POSIX primitives as directly as possible in order<br>
to avoid race conditions.  I'm not familiar enough with Windows to<br>
suggest patches to its implementation, though.<br></blockquote></div><br>Hi Matthew, I would like to understand what you did and in what sense it fixes anything.<div><br></div><div>If you have a look at the history of ECL's mutex implementation, formerly we would simply use POSIX. Just call the mutex routines and that's all.</div>

<div><br></div><div>Problem: there is absolutely no way to judge from POSIX whether a call to a mutex routine succeeded or was interrupted. What to do with the unwind-protect in that situation? If ECL does not keep a record of what calls to pthread_mutex_lock() succeeded and which ones did not, then the exit from with-lock will break.</div>

<div><br></div><div>I understand that the current implementation might not be very stable and still have errors, but removing the additional layer does not solve the problems, just hides some of them and causes new ones.</div>

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