Craig Swanson wrote in a message to Mike Bilow:

 MB> Application threads are blocked waiting for a device
 MB> driver.  While a device driver is reentrant, it is not
 MB> multithreaded.  The application threads can be on any
 MB> processor, but the device driver (or at least its
 MB> interrupt service routine) must be running on the
 MB> master processor.

 CS> Do you know if the concept of a "master process" for
 CS> handling ISR's will be preserved in the Warp SMP version
 CS> planned for release in 3rd quarter 1996?  Or will they
 CS> enable it to handle interrutps on any processor?

I don't know, but changing this would be a huge headache.

 MB> It doesn't make any difference whether the interrupt occurs before or
 MB> after the INC instruction, as long as the interrupt
 MB> cannot occur during the instruction.  In fact, even in

 CS> Actually what really matters is when the interrupt is
 CS> handled by the CPU, not when it happens.  There's nothing to
 CS> prevent an interrupt request line from being asserted during
 CS> the middle of an instruction,for instance.  But the CPU has
 CS> to finish processing the instruction before it can handle
 CS> the interrupt. 

The issue is whether the CPUs are running synchronously or asynchronously.

 MB> single processor systems, a one-pass instruction such
 MB> as INC can never be interrupted.  Such use of the LOCK
 MB> prefix is therefore basically pointless.  There is a
 MB> purpose for the LOCK prefix, but it is completely
 MB> unrelated to this issue.

 CS> I agree that the LOCK prefix used with INC, DEC, etc. is
 CS> pointless on a single-processor system.  But it is useful on
 CS> multiprocessor systems because it will prevent processors
 CS> from mucking with the same memory address being used by
 CS> another processor so long as they are all using the LOCK
 CS> prefix properly. 

It is useful if and only if there is bus hardware which makes use of it,
and the bus hardware should be able to prevent conflicting
read-modify-write by different processors.  The cache hardware is also
responsible for snooping and snarfing to make sure that no other processor
attempts to touch data still in the cache of another processor.
 
-- Mike


---