2

最近、Linuxソースをhttp://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.34.1.tar.bz2からダウンロードしました。linux-2.6.34.1\Documentationフォルダーにあるspinlocks.txtというファイルで以下の段落に出くわしました。

「それは、あなたがそうするコードを持っているなら、それは意味します

cli();
.. critical section ..
sti();

そして、それを行う別のシーケンス

spin_lock_irqsave(flags);
.. critical section ..
spin_unlock_irqrestore(flags);

その場合、それらは相互に排他的ではなく、クリティカル領域は2つの異なるCPUで同時に発生する可能性があります。それ自体は問題ありませんが、クリティカル領域はさまざまなものに対してクリティカルである方がよいでしょう（つまり、互いに踏みつけることはできません）。「」

一部のコードがcli（）/ sti（）を使用していて、同じコードの他の部分がspin_lock_irqsave（flags）/ spin_unlock_irqrestore（flags）を使用している場合、どのように影響しますか？

4

1 に答える 1

7

ここで重要なのは「2つの異なるCPU上」です。いくつかの背景：

  • 歴史的に、ユニプロセッサ（UP）システムでは、同時実行の唯一の原因はハードウェア割り込みでした。cli/stiIRQハンドラーが物事を台無しにするのを防ぐには、クリティカルセクションを回避するだけで十分でした。
  • 次に、カーネルが単一のCPUで効果的に実行され、一度に1つのプロセスしかカーネルに存在できないというジャイアントロックの設計がありました（ジャイアントロックの目的）。繰り返しになりますが、割り込みを無効にすることで、カーネルをそれ自体から保護するのに十分でした。
  • カーネルで複数のスレッドが同時にアクティブになり、ほとんどすべてのCPUに割り込みが配信される可能性がある、完全なSMPシステムでは、単一のプロセッサで割り込みを無効にするか、単一のロックを取得するだけではもはや十分ではありません。両方が必要です。割り込みを無効にすると、同じCPU上のIRQハンドラーから保護され、ロックを保持すると、別のCPU上の同じクリティカルセクションに入る他のスレッドから保護されます。これがまさにその理由spin_lock_irqsave()であり、spin_unlock_irqrestore()発明されました。
于 2010-07-17T03:04:29.937 に答える