問題タブ [spinlock]

スピンロックはスピニングで機能し、さまざまなカーネルパスが存在し、カーネルはプリエンプティブであることがわかっています。それでは、なぜスピンロックがユニプロセッサシステムで機能しないのでしょうか。（たとえば、Linuxの場合）

Linuxデバイスドライバーをフォローしています。スピンロックを導入すると、次の例が示されます。

ドライバーが実行中で、デバイスへのアクセスを制御するロックを解除しました。ロックが保持されている間、デバイスは割り込みを発行します。これにより、割り込みハンドラーが実行されます。割り込みハンドラは、デバイスにアクセスする前に、ロックも取得する必要があります。割り込みハンドラーでスピンロックを取得することは、正当なことです。これが、スピンロック操作がスリープしない理由の1つです。しかし、割り込みルーチンが最初にロックを解除したコードと同じプロセッサで実行された場合はどうなりますか？割り込みハンドラーが回転している間、非割り込みコードを実行してロックを解除することはできません。そのプロセッサは永久に回転します。

割り込みハンドラーが回転していると、割り込みなしのコードを実行できない理由がわかりません。

割り込みハンドラのルーチンをプリエンプションできないからですか？もしそうなら、それは割り込みルーチンがアトミックでなければならないということですか？

プロセスがいくつかのスピンロックまたはセマフォを保持していて、誤って終了した場合（たとえば、Linuxによって強制終了された場合）、Linuxはこれらのロックを正しく解放しますか？Linuxがこの機能を果たさないのなら、なぜですか？

Linux では、kvm 環境で、VM 内のプロセスがリソースをロックして横取りされると、そのロックされたリソースを必要とする VM の他のプロセスがスピンロックに時間を費やします。また、プロセスは、PROCESSOR が割り当てられると、リソースのロックを解除します。

プロセスがリソースのロックを解除するまで、スケジューラのプリエンプティを無効にしたいと考えています。これにより、スピンロックのCPU時間が短縮されます。

上記を達成する方法?? すなわち

1. VM のプロセスがリソースをロックしているかどうかを確認する方法は?

2. 次に、リソースのロックが解除されるまでプロセスを先取りしないようにスケジューラに通知する方法は?

どこか間違っている場合は修正してください..

前もって感謝します..

このクラスがどのように作成されたか、またいつ使用すべきか、使用すべきでないかについてのロジックを理解しようとしています。どんな洞察もいただければ幸いです

更新: ソース コードで使用例を見つけました...これは、上記のオブジェクトの使用方法を示していますが、「理由」はわかりません。

Linuxデバイスドライバー。スピンロックを導入すると、次の例が示されます。

ドライバーが実行中で、デバイスへのアクセスを制御するロックを解除しました。ロックが保持されている間、デバイスは割り込みを発行します。これにより、割り込みハンドラーが実行されます。割り込みハンドラは、デバイスにアクセスする前に、ロックも取得する必要があります。割り込みハンドラーでスピンロックを取得することは、正当なことです。これが、スピンロック操作がスリープしない理由の1つです。しかし、割り込みルーチンが最初にロックを解除したコードと同じプロセッサで実行された場合はどうなりますか？割り込みハンドラーが回転している間、非割り込みコードを実行してロックを解除することはできません。そのプロセッサは永久に回転します。

この問題を解決するにはどうすればよいですか？セマフォを使用していますか？助けてください。

で次のスピンロック コードを見つけましたboost::smart_ptr。

したがって、これを正しく理解していれば、ロックが競合すると、着信スレッドは指数関数的にバックオフし、最初に乱暴にスピンし、次に一時停止し、タイム スライスの残りを明け渡し、最後にスリープと明け渡しの間でフリップ フロップします。

glibc pthread_spinlockまた、アセンブリを使用してロックを実行する実装も見つけました。

アセンブリについての私の理解が不十分であることは認めます。そのため、ここで何が起こっているのかを完全には理解していません。（誰かがこれが何をしているのか説明してもらえますか？）

ただし、ブースト スピンロックと glibc pthread_spinlock に対していくつかのテストを実行したところ、スレッドよりもコアが多い場合、ブースト コードは glibc コードよりも優れたパフォーマンスを示しました。

一方、コアよりもスレッドが多い場合は、glibc コードの方が優れています。

どうしてこれなの？これら 2 つのスピンロックの実装の違いは、シナリオごとに異なるパフォーマンスをもたらすことは何ですか?

私は次のコードを持っています：

PRINTが1として定義されている場合、最後に正しいカウンター値を取得します。

0にするPRINTと、次のようになります（複数回実行）。

何が起こっているのかについての洞察はありますか？printステートメントを有効にすると、結果は（一貫して）正しいのに、無効にするとカウンターが目標値に達しないのはなぜですか？私はpthreadをかなり使用しましたが、スピンロックを直接使用した経験はあまりありません。

ヘルプやフィードバックをいただければ幸いです。

SpinLockを使用しようとしていますが、シングルスレッドコンソールアプリのこの最も基本的なコードでさえ、SpinLock.Exit（）を呼び出すと次の例外がスローされます。

これがソースコード全体です...

私はかなり長い間これを読んできましたが、私には意味がありません..おそらく、私はこれらすべてに不慣れで、カーネルの概念をほとんど理解していないためです。

これは私が思いついたものです（エラーやNULL処理はありません。質問のためだけです）：

カーネル スピンロックは、プリエンティブなカーネル スレッド内で実行されます。