On Sun, 14 Jul 1996, Jan-Simon Pendry wrote:

> % > : spl is probably fundamentally wrong for SMP.  I haven't thought much
> % > : about what to use instead.
> % > 
> % > The Solbourne people might disagree with you.  As might the VMS
> % > Digitial people.  Both groups used a scheme where you would raise the
> % > spl *AND* grab access locks to data structures (I think the latter was
> % 
> % It's the quick and dirty route to getting an SMP version out the door
> % under budgetary or market timing constraints. 
> % 
> % To do it right, sections of code have to be rewritten to make the code as
> % parallel as possible. 
> % 
> % Caching also works very differently with multiple CPU's.
> 
> unless you redesign the interrupt mechanism, you still have to
> raise spl levels for locks on data structures that can be accessed
> from interrupt handlers (or timeouts etc).  if the cpu runs at the
> normal spl, it may end up taking an interrupt and then trying to
> lock a structure that the interrupted thread on the cpu had already
> locked.
> 

A point I should clarify is that spls are still necessary.  They are just
placed in the critical sections of code written with the assumption that
the there is only one CPU.

So you can say, "Well, I can just #define splxxx to something else".  But
this wouldn't be as good as doing something like identifying the critical
sections that can take advantage of things like multireader locks and
restructuring these sections of code if necessary.

I've read about all this in the following books:

Unix Internals: The New Frontiers by Uresh Vahalia
Unix Systems for Modern Architectures by Curt Schimmel of SGI

I noticed some technical papers at Sequent's web site.  I haven't looked
at them yet so I don't know how detailed they are.  I'm interested in
finding more material to pick up where the above two books left off.

-mike hancock