>> 
>> I really don't think that Solaris could be taken as a sane example
>> of what "true" multiprocessing should be. A much better example would
>> be sorta like early SGI variant kernels I saw at Kubota (Ardent):
>> one atomic operation (spinlock, with h/w timeout/death) and a P/V semaphore
>> built on top of that to replace/supplement sleep/wakeup. Period.
>
>Hmm, does this approach make sense in the context of systems with say N
>or more CPU's?  The MP performance of Solaris has been getting better 
>and better each release, or so sun says.  If you have say 32 CPU's, 
>can you get away with doing things any less stringently and still get
>the same level of performance?
>

I think my point wasn't clear enough. With just a single simple
locking mechanism that blows up the machine on recursive entry *or*
on timeout the kernel programmer is forced to be *really* tight
at avoiding contention and *must* rethink code that can be reentrant.

With Solaris, you've now seen a 6 year evolution of both faster
harware making MP "seem" better and periodic "performance" hunts
to identify really stupid locking strategies (i.e., pointless
re-locking thrash because you're upgrading a reader-writer lock
from readable to writable).

Don't get me wrong: there's been a lot of very smart people working *very*
hard at Sun- it's a pity that they let a 1988 MP Architecture Document
(that's the date of the document that defined all this stuff) give them
agita 8 years later.