Interrupt Handling on SMP Systems

Question

Are Interrupts assigned to a fixed CPU (always handled by the same CPU)?

To put my question in context:

From: http://msdn.microsoft.com/en-us/library/ms795060.aspx

The spin lock that protects the shared area has an IRQL equal to the DIRQL at which the device interrupts. As long as the critical-section routine holds the spin lock and accesses the shared area at DIRQL, the ISR cannot be run in either a uniprocessor or SMP machine.

That makes sense on a uniprocessor machine as the interrupt will not be serviced by the CPU until the lock is released since the IRQL of the CPU is not less than the interrupt IRQL. On a SMP machine however, what would prevent the interrupt to be handled by the other CPU (not the CPU owning the lock) and corrupt the data... ?

Answer 1

Reading the next section ...

In an SMP machine, the ISR cannot acquire the spin lock that protects the shared data while the critical-section routine holds the spin lock and accesses the shared data at DIRQL.

... I think that's saying that on an SMP machine an interrupt can happen; but that if the interrupt happens, then the interrupt service routine (running on the other CPU) still can't acquire the spin lock: i.e. it spins, wasting cycles, trying the acquire the spin lock, unless you release the spin lock which lets the waiting ISR acquire it.

I was wondering why it might allow an ISR to run on the other CPU, instead of masking interrupts (to prevent the ISR being started) as it does in single-CPU case. An answer to that is that, no matter whether or not new ISRs can be started on the other CPU while the spinlock is held, the fact is that (unlike in the single-CPU case) an ISR might already be running on the other CPU at the moment when the DIRQL spinlock is started: and it's for that reason that such an ISR (if it exists on the other CPU) must spin (if it tries to acquire the spinlock).