I wrote:

[Tom I Helbekkmo <tih@Hamartun.Priv.NO> wrote]

>>Most
>>other NetBSD platforms will be very, very easy to get running for
>>someone who is able to implement a simple test-and-set spin lock for
>>the hardware in question in assembly.

>But what about processors that cant do test-and-set?  Should we
>introduce a new MD syscall or fastpath trap for them, or what?

Since I've gotten some questions about this:

The mips1 CPU family (r2000, r3000) has no CPu support for atomic
operations whatsoever.  Implementing test-and-set (or any other
indivisibile primitive, like CAS) on these CPUs requires either
external hardware (as provided on SGI multiprocessors using these
CPUs), or kernel support.

There are a couple of software techiqnues. You can implement a
fastpath kernel trap which disables interrups and does the atomic
operation entirely in the kernel. 


Or, you can hardwire the atomic-operation code into a fixed address in
each process and have the scheduler check for, and avoid, context
switching away from a process in the middle of an atomic operation.

IIRC, Bershad's technique is to have the scheduler check the victim's
PC, and finish the atomic operation on behalf of the victim user
process, fixing up the saved register state as if the operation had
already been done, and resuming _after_ the operation.  That isnt too
bad for a single, known, atomic operation on a load/store machine.  I
dont know what happens when you need to change the userspace mutex
code.

Sigh. It'd be nice if PostGres was designed to better support broken
CPUs, but one cant be too disappointed that they dont.