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.
