Linuxカーネルの基本的なスピンロックアルゴリズムを置き換えるチケットロックアルゴリズムに精通している人はいますか? 私はこれについて専門家を見つけることを望んでいます。単純なアルゴリズムはすべてのスレッドが同時にロックを取得しようとしてCPUバスを圧倒するため、チケットロックアルゴリズムはより高速であると思われるいくつかのオンラインソースから読みました。誰かが私のためにこれを確認/拒否できますか?
私は自分自身のいくつかの実験をしました。チケット ロックは確かに公平ですが、そのパフォーマンスは pthread スピンロック アルゴリズムとほぼ同等です。実際、少しだけ遅くなります。
私の見方では、不公平なアルゴリズムは、早い段階でロックを占有するスレッドがより迅速に終了し、スケジューラの作業が少なくなるため、少し高速になるはずです。
このことについて、もう少し広い視野を持ってみたいと思います。高速でない場合、チケットロックがカーネルに実装されているのはなぜですか?ユーザー空間で使用されないのはなぜですか? ありがとう！
Linuxカーネルの基本的なスピンロックアルゴリズムに代わるチケットロックアルゴリズムに精通している人はいますか？私はこれに関する専門家を見つけることを望んでいます。いくつかのオンラインソースから、チケットロックアルゴリズムの方が高速であると考えられていることを読みました。これは、ナイーブアルゴリズムが、すべてのスレッドが同時にロックを取得しようとしてCPUバスを圧倒するためです。誰かが私のためにこれを確認/拒否できますか？
私は自分でいくつかの実験をしました。チケットロックは確かに公平ですが、そのパフォーマンスはpthreadスピンロックアルゴリズムとほぼ同等です。実際、それはほんの少し遅いです。
チケットロックの導入は、主に公平性の理由によるものだと思います。チケットロックとスピンロックの速度とスケーラビリティは、MCSのようなスケーラブルロックと比較してほぼ同じです。それらの両方は、CPUバスを圧倒する多くのキャッシュライン無効化とメモリ読み取りを導入します。
私の見方では、不公平なアルゴリズムは少し速くなるはずです。なぜなら、早い段階でロックを占有するスレッドがより速く終了し、スケジューラーが行う作業が少なくなるからです。
関係するスケジューラーはありません。チケットロックとスピンロックはビジーウェイトロックであり、待機中はブロックされませんが、ロック値を確認してください。ロックが解除されると、プログラムは続行します。制御フローがスケジューラーに行き、戻ってくることはありません。ブロックウェイクアップロックの代わりにスピンロックを使用する理由は、ブロックウェイクアップにはコンテキストスイッチが含まれるためです。これは高価です。代わりに、待機してCPU時間を燃焼する方が安価です。したがって、ビジー待機ロックは「短い」クリティカルセクションでのみ使用できます。
これについてもう少し見方をしたいと思います。高速ではない場合、なぜチケットロックがカーネルに実装され、なぜユーザースペースで使用されないのですか？ありがとう！
カーネルコードにもクリティカルセクションがあるため、カーネル内にあります。カーネルデータを保護するには、カーネルスペースロックが必要です。ただし、もちろん、使用スペースチケットロックを実装して、アプリケーションで使用することもできます。