中断是否分配给固定的 CPU（总是由同一个 CPU 处理）？
把我的问题放在上下文中：
来自：http: //msdn.microsoft.com/en-us/library/ms795060.aspx
保护共享区域的自旋锁的 IRQL 等于设备中断的 DIRQL。只要临界区例程持有自旋锁并访问 DIRQL 的共享区域，ISR 就不能在单处理器或 SMP 机器上运行。
这在单处理器机器上是有意义的，因为在释放锁之前 CPU 不会处理中断，因为 CPU 的 IRQL 不小于中断 IRQL。然而，在 SMP 机器上，什么会阻止其他 CPU（不是拥有锁的 CPU）处理中断并破坏数据......？
阅读下一节...
在 SMP 机器中，ISR 无法获取保护共享数据的自旋锁，而临界区例程持有自旋锁并在 DIRQL 访问共享数据。
...我认为这是说在 SMP 机器上可能会发生中断；但是如果中断发生，那么中断服务例程（在另一个 CPU 上运行）仍然无法获取自旋锁：即它自旋，浪费周期，尝试获取自旋锁，除非您释放自旋锁等待的 ISR 获取它。
我想知道为什么它可能允许 ISR 在另一个 CPU 上运行，而不是像在单 CPU 情况下那样屏蔽中断（以防止启动 ISR）。对此的回答是，无论在持有自旋锁时是否可以在另一个 CPU 上启动新的 ISR，事实是（与单 CPU 情况不同）一个 ISR 可能已经在另一个 CPU 上运行在 DIRQL 自旋锁启动的那一刻：正是由于这个原因，这样的 ISR（如果它存在于另一个 CPU 上）必须自旋（如果它试图获取自旋锁）。
我的理解是，当系统将 DIRQL 提升到某个级别时，任何处于该 DIRQL 或更低级别的中断都会在所有处理器上被有效禁用。这就是为什么您不应该将 IRQL 提高到超过绝对需要保持的时间。
很少有驱动程序代码需要将 IRQL 提升到高于调度级别的级别（这不会屏蔽任何中断）。唯一需要提高 IRQL 的驱动程序代码是实际需要与中断处理程序交互（共享数据）的代码。
编辑：ChrisW 对 SMP 系统中发生的事情有更好的描述——提高处理器上的 IRQL 将阻止 IRQ 在该特定处理器上被处理。如果中断处理程序被调度在另一个 CPU 上，而保护共享数据的自旋锁由第一个 CPU 持有，则中断处理程序将在其 CPU 上自旋，直到第一个 CPU 释放自旋锁（要按操作访问共享数据，中断处理程序必须获取自旋锁，这是强制中断处理程序等待的原因）。
所以保持这些自旋锁尽可能短（并且尽可能不频繁）。