カーネル スペース内のプロセスが を保持しているspin_lock場合、次のいずれかの条件が原因で、プロセスを横取りできません。
ただし、プロセスがブロック、スリープ、または明示的に を呼び出す場合、プロセスはプロセッサを譲ることができますschedule()。私の理解は正しいですか？
カーネル空間のプロセスが を保持している場合mutex_lock、上記の 1、2、および 3 の条件により、プロセスが横取りされる可能性があります。
スピン ロックの現在の実装では、2 つの完全に別個のメカニズムを使用して相互排除を保証しています。
2 つ以上のプロセッサ コア間でミューテックスを提供するためだけに存在する spin_lock 自体があります。ロックされたスピンロックにヒットしたプロセッサは、基本的に別のプロセッサが解放するまでスタックします。スピン ロックは、シングル プロセッサ システムでは、完全なデッドロックの可能性を高める以外には何の役にも立たないため、通常はカーネルのコンパイル時に削除されます。
ローカル プロセッサ ミューテックスを提供するために、spin_lock() は preempt_disable() (プリエンプティブ スケジューリング システムで) を呼び出して、ロックが保持されている間は他のスレッドが実行されないようにします。同様に、spin_lock_irqsave() も local_irq_save() と同等の処理を行い、割り込みを無効にして、ローカル プロセッサで他の処理が実行されるのを防ぎます。
上記から明らかなように、スピン ロックを使用するとマシン全体に負荷がかかる可能性があるため、スピン ロックは非常に短い期間だけ使用する必要があり、ロックを保持している間は再スケジュールを引き起こす可能性のあることは絶対に行わないでください。
mutex_lock の場合はまったく異なります。ロックにアクセスしようとするスレッドのみが影響を受け、スレッドがロックされたミューテックスにヒットすると、再スケジュールが発生します。このため、mutex_locks は割り込み (または他のアトミック) コンテキストでは使用できません。