[Mono-dev] _wapi_sparc_lock

[David S. Miller]

Now that I have the sparc-linux build working I've been
hunting down testsuite failures.

Occaisionally I get a complete wedge, and after analyzing
a few forced core dumps when this happens it's always
sitting there spinning on the _wapi_sparc_lock in atomic.h
used to implement atomics.

This spinlock scheme doesn't work well, because if a signal
or exception is taken while the _wapi_sparc_lock is held we
can easily reenter one of these atomic routines and try to
take the lock recursively.  Even worse, if we take the lock,
and then receive a signal which causes a stack unwind back
up to a function before one of the atomic routines, we'll
leave the lock held and never relase it.  The next thread
to do an atomic will hang.

A third case would be a signal received that causes the thread to
exit, like case #2 this would also leave the _wapi_sparc_lock held.

In short, this doesn't work.

The reason we use this funny lock is that Sparc cpus before
UltraSPARC only have this "ldstub" spinlock instruction.

Supporting these older chips becomes less and less important
over time in my opinion, so we really should move over to
using the true "compare and set" atomic instructions provided
by UltraSPARC and later.  Current Solaris releases don't even
support pre UltraSPARC chips any longer and Linux/SPARC didn't
even build and support exceptions properly until today.

If we really really want to keep the spinlocks in there we'll
have to do something like block signals during the atomics,
and that is _very_ heavy handed, and expensive to the point
where I think it's a unaccaptable to consider this approach.

In any event, I can provide a patch to use the proper modern
atomic instructions.  And I'll work on that while this thread
discussion occurs.