On (26 Feb 97) James Vahn wrote to Jerry Coffin...
 JV> I've recently been wondering about multiprocessor boards-- how on
 JV> earth would a guy code for them?  Does each processor have it's own 
 JV> RAM, or do they share a common spool in some fashion?
At least as they're being implemented in PCs, each processor has its own
interrupt controller and at least some cache.  However, they all share
RAM and things like serial ports.
This is what's known as a tightly coupled multiprocessor.  The shared
RAM tends to form a bottleneck, and acts as a limit on the number of
processors you can have in a machine.  Depending on the caching in use,
the limit is typically somewhere between 4 and 64 processors - more
caching allows the use of more processors.  However, even with caching,
you end up with one processor having to invalidate the contents of other
processors' caches, making the caching less effective.  Using lots of
processors typically involves reducing the requirements for cache
coherency - i.e. when one processor changes a location, the other
processors might not see that change immediately.  However, when we
allow this, we have to compensate for it in the programming somehow, so
it tends to be less popular.
The other major group of multiprocessor mahines are loosely coupled
machines.  Instead of sharing RAM to communicate between processors,
these act a bit more like a network of separate machines: each has its
own RAM, and they have sort of high speed communications mechanism
between the processors.  This will generally allow for a much larger
number of processors, allowing (at least theoretically) much higher
performance.  However, communications between processors are still a
problem.  For instance, if we have 1000 processors, it's completely
impractical to have a high speed line from each processor to each other
processor.  This is where people come up with various different
topologies that atttempt to 1) reduce the number of communication lines
as much as possible, and 2) still maintain fast communications between
any particular pair of CPUs.
 JV> Saw an article the other day that implied future upgrades to a PC 
 JV> will involve adding more processors. Your next desktop would have the
 JV> potential to become a supercomputer using off-the-shelf (Intel?)
 JV> components.
It's available now, if you want to go that route.  Pick up a copy of
Windows NT Server, and a 4 processor machine for Dell, Compaq, etc., and
you're there.
Under most OSes that support multiprocessing, about all you have to do
in your program to take advantage of it is to write multithreaded
programs.  As it happens, multithreading makes a lot of programs quite a
bit simpler anyway, so when it's available, most programmers use it even
though they're not particlarly concerned about multiprocessor
performance.
(I should point out that there are quite a few other multiprocessor OSes
as well, but few of them seems to have the market impact, or the number
of programs availble as NT.)
If you're interested in multiprocessor programming at the hardware
level, I'd advise hitting Intel's web site: they have a multiprocessor
hardware specification available for download.  All the PC's I know of
that are doing multiprocessing are following this spec.
    Later,
    Jerry.
... The Universe is a figment of its own imagination.
--- PPoint 1.90
---------------