[Ecls-list] MP stability improvement

[Matthew Mondor]

On Sat, 11 Feb 2012 23:47:06 +0100
Juan Jose Garcia-Ripoll <juanjose.garciaripoll at googlemail.com> wrote:

> On Sat, Feb 11, 2012 at 10:14 PM, Juan Jose Garcia-Ripoll <
> juanjose.garciaripoll at googlemail.com> wrote:
> 
> > I believe this would still work in the Windows implementation, where locks
> > are always recursive, but it strongly relies on having libatomics compiled
> > in for CAS support.
> >
> 
> Sorry, I mixed up the code of the two functions a bit. I notice that there
> is still a problem when the code gets interrupted before the owner is set
> and the user does not unwind. This would happen, for instance, when the
> thread is suspended by the garbage collector.
> 
> I have been toying for the last hour with alternatives, but while there are
> some that profit from POSIX's error detection by forcing all locks to be
> non-recursive, those do not work at all in Windows.
> 
> Definitely this all is rather messy :) I wonder whether it would make sense
> to use CAS + wait times as SBCL does.

It's unfortunately a rather complex problem and I'll have to carefully
re-read your last messages more than once, it seems :)

One of the reasons for me to use ECL on NetBSD (apart from the awesome
C integration) is that threads are supported.  SBCL only supports
threads on a few specific systems, yet I think that there is work
ongoing on that lately, which I haven't followed much.

CAS being almost universally supported by architectures
(implementations might be slow on a few specific ones such as VAX), yet
totally OS-independent, I guess that it'd be a good research area for
an experimental lock implementation, indeed...

PThread Mutex code is generally also dealing with issues such as memory
barriers, I wonder if a custom implementation would also have to.  I'm
not sure yet about other OSs, but NetBSD exports those along with its
atomic_ops(3).
-- 
Matt