Spinlocks and CPU Architectures

The long history of spinlock issues has recently been attacked
significantly by Tom, but I wanted to get a status on this issue before
we release 8.1

My understanding of the problems of spinlocking has been greatly
enhanced by two recent articles:

Linux Journal, discussing linux SMP portability issues across multiple
CPU architectures
http://www.linuxjournal.com/article/8211
http://www.linuxjournal.com/article/8212

A similar blog from an MS guy, who has been looking into porting the MS
CLR across to multiple CPUs, rather than just x86 arch & derivatives.
This article was the nearest I could find to an article I found in the
most recent copy of the MS Developer Journal, that discussed multi-
processor synchronisation techniques.
http://blogs.msdn.com/cbrumme/archive/2003/05/17/51445.aspx

The conclusion I draw from all of this is that the spinlock code needs
to be specialised for individual hardware architectures, not just
instruction sets. That is, we need different code for Intel and AMD, as
well as for other CPU types - *if* you want it to perform well for SMP.

>From the experience with Xeon and Xeon MP, it also seems to be the case
that different CPU variants and implementations cause different memory
access behaviours in SMP systems to single/dual CPUs.

That's bad news for portability and for producing binaries, but we
should not use that as a reason to avoid facing up to the situation. The
rest of the world does seem to try quite hard to limit portability and
the articles above show that others must also be experiencing the same
difficulties.

Do other people reach the same conclusions?

Can we make a list of those architectures for which 8.1 is known to
perform reasonably well, with reasonable SMP scalability? I suggest that
we record this list somewhere in the release notes, but with a comment
to say we run on other architectures, but they have not been SMP tested
as of date of announcement. That is important, since the release notes
make specific claim about scalability features.

Best Regards, Simon Riggs