割り込みは固定CPUに割り当てられていますか（常に同じCPUによって処理されます）？
私の質問を文脈に当てはめるには：
差出人：http ： //msdn.microsoft.com/en-us/library/ms795060.aspx
共有領域を保護するスピンロックのIRQLは、デバイスが割り込むDIRQLと同じです。クリティカルセクションルーチンがスピンロックを保持し、DIRQLの共有領域にアクセスする限り、ISRはユニプロセッサまたはSMPマシンのいずれかで実行できません。
CPUのIRQLは割り込みIRQL以上であるため、ロックが解除されるまで割り込みはCPUによって処理されないため、ユニプロセッサマシンではこれは理にかなっています。ただし、SMPマシンでは、割り込みが他のCPU（ロックを所有しているCPUではない）によって処理され、データが破損するのを防ぐにはどうすればよいでしょうか...？
次のセクションを読む...
SMPマシンでは、クリティカルセクションルーチンがスピンロックを保持し、DIRQLで共有データにアクセスしている間、ISRは共有データを保護するスピンロックを取得できません。
...これは、SMPマシンでは割り込みが発生する可能性があることを意味していると思います。ただし、割り込みが発生した場合でも、割り込みサービスルーチン（他のCPUで実行）はスピンロックを取得できません。つまり、スピンロックを解除しない限り、スピン、サイクルの浪費、スピンロックの取得を試みます。待機中のISRがそれを取得します。
シングルCPUの場合のように（ISRが開始されないように）割り込みをマスクするのではなく、なぜISRを他のCPUで実行できるのか疑問に思いました。その答えは、スピンロックが保持されている間に他のCPUで新しいISRを開始できるかどうかに関係なく、（単一CPUの場合とは異なり）ISRがすでに他のCPUで実行されている可能性があるということです。 DIRQLスピンロックが開始された時点で：そのため、そのようなISR（他のCPUに存在する場合）はスピンする必要があります（スピンロックを取得しようとする場合）。
私の理解では、システムがDIRQLを特定のレベルに上げると、そのDIRQL以下の割り込みはすべてのプロセッサーで事実上無効になります。そのため、絶対に保持する必要があるよりも長くIRQLを上げるべきではありません。
IRQLをディスパッチレベルより上のレベルに上げる必要のあるドライバーコードはほとんどありません（これにより、割り込みがマスクされません）。IRQLを高くする必要がある唯一のドライバーコードは、割り込みハンドラーと実際に対話する（データを共有する）必要があるコードです。
編集：ChrisWは、SMPシステムで何が起こっているかについてより良い説明をしました-プロセッサでIRQLを上げると、その特定のプロセッサでIRQが処理されなくなります。共有データを保護するスピンロックが最初のCPUによって保持されている間に、割り込みハンドラーが別のCPUでスケジュールされている場合、割り込みハンドラーは、最初のCPUがスピンロックを解放するまでそのCPUでスピンします（共有データに永続的にアクセスするには、割り込みハンドラーが必要です。スピンロックを取得します。これにより、割り込みハンドラが強制的に待機します）。
したがって、これらのスピンロックをできるだけ短く（そしてできるだけ頻繁に）保持します。