Re: mutexes, locks and so on...

[Andrew Doran <ad%homeworld.netbsd.org@localhost>]

On Fri, Nov 12, 2010 at 01:56:20PM +0100, Joerg Sonnenberger wrote:
> On Thu, Nov 11, 2010 at 06:35:55PM +0100, Johnny Billquist wrote:
> > Hmm. Hard to argue about this. While I think it's nice if we try to
> > keep the kernel agnostic, the user api is not something I'm arguing
> > about changing. But it would be nice if we could leave it possible
> > to do things in different ways when it's not really the effect of a
> > CAS that is needed, but we'd still like to keep it in a way that
> > allowed the compiled code to be as nice and efficient as possible.
> 
> A CAS is pretty much the standard low-level primitive in the literature.
> Either CAS or LL/SC are available in pretty much all non-ancient CPUs
> and CAS can be emulated with LL/SC easily. If you really want to spend
> time on reducing the overhead for VAX, implement ras(9) like behavior
> for the kernel. That requires changing all trap entry points OR all trap
> exit points to check if the return address is inside a special range
> (e.g. a page that implements CAS and maybe a few other atomic ops) and
> do a second level lookup if it is to backout to the start of the
> routine. The problem with this approach is that it creates very nasty
> bugs if you skip even a single instance.

The atomic ops for aincent MIPS (MIPS1) work like this.  There is no
prospect for SMP on MIPS1 though.