問題タブ [spinlock]

マルチスレッドコードには多くのスピンロックがあり、ほとんどの場合、他のスレッドが機能するのを待っているため、CPU使用率が大幅に低下します。Linuxでは、通常、pthread_cond_waitとpthread_cond_signalを使用してスレッドを一時停止し、シグナルが送信されたときにウェイクアップします。Boostライブラリにこのようなものはありますか？ざっと見てみると、何も見つかりませんでした。

Visual Studio 2005

非常に小さなクリティカル セクションを保護するためにスピン ロックを使用しています。競合が発生することはめったにないため、スピン ロックは通常のミューテックスよりも適切です。

私の現在のコードは次のとおりで、x86 と GCC を想定しています。

だから私は疑問に思っています：

• このコードは正しいですか? 相互排除を正しく保証していますか?
• すべての x86 オペレーティング システムで動作しますか?
• x86_64 でも動作しますか? すべてのオペレーティング システムで?
• 最適ですか？
  • コンペア アンド スワップを使用したスピン ロックの実装を見たことがありますが、どちらが優れているかはわかりません。
  • GCC アトミック組み込みドキュメント ( http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html ) によると、 __sync_lock_release. 私はメモリ バリアの専門家ではないので、 の代わりにこれを使用してもよいかどうかわかりません__sync_synchronize。
  • 競合がない場合に最適化しています。

私は競合についてはまったく気にしません。数日に 1 回、スピン ロックをロックしようとしているスレッドが他に 1 つまたは 2 つある可能性があります。

コードでスピンロックを実際に使用している頻度はどれくらいですか? ビジー ループを使用した方が実際にロックを使用した場合よりもパフォーマンスが優れているという状況に遭遇することは、どのくらいよくあることでしょうか?
個人的には、スレッド セーフが必要なコードを書くときは、さまざまな同期プリミティブを使ってベンチマークする傾向があります。その限りでは、スピンロックを使用するよりもロックを使用した方がパフォーマンスが向上するようです。実際にロックを保持している時間がどれだけ短いかに関係なく、スピンロックを使用した場合に発生する競合の量は、ロックを使用した場合よりもはるかに多くなります (もちろん、私はマルチプロセッサ マシンでテストを実行しています)。

「低レベル」のコードでスピンロックに遭遇する可能性が高いことは認識していますが、より高レベルの種類のプログラミングでも役立つかどうか知りたいですか?

Windows のインターロック機能を使用して非常に単純なスピンロックを作成し、デュアルコア CPU (変数をインクリメントする 2 つのスレッド) でテストしました。

プログラムは正常に動作しているように見えます (毎回同じ結果が得られますが、同期が使用されていない場合はそうではありません) が、インテル® Parallel Inspectorは値 += jで競合状態があることを示しています (以下のコードを参照)。SpinLock の代わりにクリティカル セクションを使用すると、警告が表示されなくなります。

SpinLock の実装は正しいですか? 使用されるすべての操作はアトミックであり、適切なメモリ バリアがあり、競合状態につながるべきではないため、これは非常に奇妙です。

テストプログラム:

私のUbuntuマシンでは、実行中のデフォルトのカーネルイメージがsmp（CONFIG_SMP=y）用にビルドされています。しかし、このマシンには1つのCPUしかありません。

ユニプロセッサカーネルでは、smpカーネルとは異なり、spin_lock/unlocknull関数です。では、この設定ではどのようspin_lock()にspin_unlock()動作しますか？

そのようなsmp固有のコードによるパフォーマンスへの影響はありますか？

私はいつもそれらが何であるか疑問に思っていました.それらについて聞くたびに、未来的なフライホイールのようなデバイスのイメージが頭の中で踊る（転がる？）.

彼らは何ですか？

私は次のスピンロックアプローチを使用しています。

これは基本的に、ユーザーがアクションを実行するのを待ってからそれを返します。現在、何かが続行する前にユーザーからの回答を要求しているため、入力が受信されるまで待機します。ただし、これが非効率的であるかどうか、しばらく待っている場合（つまり、30秒未満）、このアプリを実行しているPCの速度が低下するのではないかと考えていました。このアプローチを使用する他の選択肢、つまりロック、セマフォがある場合、構文は何ですか？

ありがとう、

アリー

共有メモリに書き込む「サーバー」プログラムと、メモリから読み取るクライアント プログラムを作成しました。サーバーには、書き込み可能なさまざまな「チャネル」があります。これは、アイテムを追加しているリンクリストが異なるだけです。クライアントは、リンクされたリストのいくつかに関心があり、それらのリストに追加されたすべてのノードを、可能な限り最小限のレイテンシーで読み取りたいと考えています。

クライアントには2つのアプローチがあります。

1. リンクされたリストごとに、クライアントは「ブックマーク」ポインタを保持して、リンクされたリスト内の場所を維持します。リンクされたリストをラウンド ロビンし、それらすべてを何度も反復し (永遠にループします)、可能であれば各ブックマークを毎回 1 ノードずつ進めます。それができるかどうかは、ノードの「次の」メンバーの値によって決まります。null 以外の場合、次のノードへのジャンプは安全です (サーバーはそれを null から非 null にアトミックに切り替えます)。このアプローチは問題なく機能しますが、繰り返し処理するリストが多数あり、更新を受け取るリストがごくわずかである場合、レイテンシーが悪化します。

2. サーバーは、各リストに一意の ID を付与します。サーバーがアイテムをリストに追加するたびに、リストの ID 番号もマスターの「更新リスト」に追加します。クライアントは 1 つのブックマーク (更新リストへのブックマーク) のみを保持します。ブックマークの次のポインタが null でないかどうか ( ) を際限なくチェックし、while(node->next_ == NULL) {}そうである場合は先に進み、指定された ID を読み取り、その ID を持つリンク リストの新しいノードを処理します。理論的には、クライアントは毎回すべてのリストを反復処理する必要がないため、多数のリストをより適切に処理できるはずです。

両方のアプローチのレイテンシを (gettimeofday を使用して) ベンチマークしたところ、驚いたことに #2 はひどかった。最初のアプローチは、リンクされたリストの数が少ない場合、多くの場合、20us 未満のレイテンシになります。2 番目のアプローチでは、低レイテンシーの小さなスパッツがありますが、多くの場合、4,000 ～ 7,000us です。

gettimeofday をあちこちに挿入することで、アプローチ 2 で追加されたすべてのレイテンシが、次のポインターが null でないかどうかを繰り返しチェックするループで費やされていることがわかりました。これは私には不可解です。2 番目のアプローチでは、1 つのプロセスでの変更が 2 番目のプロセスに「発行」されるまでに時間がかかっているようです。ある種のキャッシュの相互作用が起こっていると思いますが、私にはわかりません。どうしたの？

更新：もともと、アプローチ＃2は条件変数を使用していたため、node->next_ == NULL条件を待機すると、サーバーは更新を発行するたびに条件を通知しました。レイテンシーは同じで、コードを上記のアプローチにまで減らした理由を理解しようとしました。マルチコア マシンで実行しているため、1 つのプロセスのスピンロックが他のプロセスに影響を与えることはありません。

更新 2: node->next_ は揮発性です。

SMPマシンでは 、割り込みコンテキストからspin_lock_irqsaveではなく、使用する必要があります。spin_lock_irq

フラグ（IFを含む）を保存したいのはなぜですか？

私たちに割り込む可能性のある別の割り込みルーチンはありますか？

軽量の spin_lock を実装するために、ユーザー モード スレッドで揮発性変数をスピンすることが安全かどうかはよくわかりません。tbb ソース コード tbb_machine.h:170 を調べました。

そして、私が見ることができるように、atomic_backoff クラスにはフェンスがありません。他のユーザーモードの spin_lock 実装からのものですが、それらのほとんどは CAS (Compare and Swap) を使用します。