3

私はカーネルプログラミングとロックを使ったプログラミングが初めてです。

さまざまな関数でスピンロックをロックおよびロック解除しても安全ですか? コードフローを同期するためにこれを行っています。

また、__schedule() でスピンロック (ロックとロック解除) を使用しても安全ですか? ロックを取得するためにスケジューラを待機させても安全ですか?

前もって感謝します。

4

3 に答える 3

0

コードを正しく設計すれば、複数の場所から同じスピンロックを取得して解放しても害はありません。実際、それがほとんどのポイントです。単一のスピンロックを使用して、Linux のatomic操作に似た一連の機能を実装できますが、必要な追加の内部複雑性はいくらでもあります。各関数内で共有リソースのロックを取得および解放する限り、問題なく動作するはずです。

主な考慮事項は次のとおりです。

  1. 各クレーム/リリース ペアの間のコードをできるだけ短くしてください。これはアトミック コンテキストです。
  2. これは、シングル コア システムで正常に機能し、プリエンプティブ SMP にスケーリングします。
  3. 実装しているコードのタイプと、それが実行されている可能性のあるコンテキストを検討し、そのために正しいタイプのスピンロックを使用する必要があります

デッドロックの可能性を念頭に置いてスピンロックを慎重に扱い、スピンロック内で行うことはすべてシステムのレイテンシーに影響を与える可能性があることを理解している限り、スピンロックは非常に便利なツールです。

ロックを要求したコード内のすべての領域が常に完了し、すぐに解放されることがわかっている場合は、コードの他の部分がロックを待機している間、スピンしていないことも同様に確信できます。これは、ミューテックスを使用するよりもはるかに効率的である可能性があります。

スピンロックを取得することのもう 1 つの利点は、それが暗黙的なメモリ バリアとして機能することです。そのため、何らかのリソース (構造体のメンバーなど) を操作する際にロックを取得することで、コードを介して他のスレッドもロックを取得することを確認できます。そのリソースを読み書きする前に、キャッシュの一貫性の問題による古い値ではなく、そのリソースの現在の状態が見られます。

複雑な問題になる可能性がありますが、その説明が少し役立つことを願っています。

于 2014-03-15T13:09:25.443 に答える
0

別の関数からスピンロック/ロック解除を使用しない正当な理由はそれほど明白ではありません。そうしない大きな理由の 1 つは、スピンロックすると、スケジューラ構造体に ATOMIC フラグが設定されるという事実です。カーネルは、この瞬間から ATOMIC コンテキストになり、スピンロックのロックを解除するまで続きます。デバッグ フラグを付けてコンパイルしたカーネルで試してみてください。klog に多くの BUG メッセージが表示されます。

幸運を。

于 2013-12-22T11:12:50.710 に答える
0

の代わりに、またはspinlockを使用できます。最も小さな一連の操作には、同じ関数で使用する必要があります。semaphoremutexspinlock

于 2013-11-05T10:09:40.803 に答える