While implementing support for Scheduler Activations in the nathanw_sa
branch I found there is a lack of support for atomic locks for our Mips
architectures.   This was required in the new libpthread library.

I coded some support using the load-linked/store-conditional primatives
only to discover from GAS that the implementation won't work for
R2000/R3000 processors:

        /tmp/ccKFYInY.s: Assembler messages:
        /tmp/ccKFYInY.s:98: Error: opcode requires -mips2 or greater `ll'

To the best of my knowledge there is no atomic locking capability in the
R3000 processor at all.   Given that we have architectures that use that
processor we cannot build using -mips2 or above.  We are faced with
supporting the lowest common denominator for now.

To make matters worse, some Mips III ISA processors (notiably the NEC
Vr4100) have not implemented ll/sc in order to save a few gates!!!

Possible solutions:

1)      Use semaphore system calls to implement atomic locks.  Expensive!
	- Will not work in the kernel

2)      Investigate using Dekker's Algorothm as a software solution.
        However, you need to know the number of processes/consumers that
        will be using the lock ahead of time.  Works for processor locks,
	(where n is known) but may not apply for pthreads (where n is a
	moving target)

3)	Bury our head in the sand and provide a best-efforts version that
	has a small race condition.

4)	Work out the CPU variant in userland and use ll/sc
	- Will need -mips2 compiler flag everywhere
	- Still need to support R3000

I would welcome any suggestions on how to solve this little problem.  We
need to have a solution in order to implement libpthreads, and it appears
we are the last architecture that doesn't have support for atomic locks.

Ideas??

Wayne