共有状態がパフォーマンスを低下させるのはなぜですか？

私は、並行プログラミングの非共有原則の下で働いてきました。基本的に、すべてのワーカースレッドには、同じ状態の不変の読み取り専用コピーがあり、それらは（参照によっても）共有されることはありません。一般的に言えば、これは非常にうまく機能しています。

現在、誰かがすべてのスレッドが同時にアクセスしているロックなしシングルトンキャッシュ（静的辞書など）を導入しています。辞書は起動後に変更されることはないため、ロックはありません。スレッドセーフの問題はありませんでしたが、現在はパフォーマンスが低下しています。

問題は...ロックがないため、このシングルトンの導入がパフォーマンスに影響を与えるのはなぜですか？これを説明できるカバーの下で正確に何が起こっていますか？

確認するために、この新しいシングルトンにアクセスすることが唯一の変更であり、キャッシュへの呼び出しをコメントアウトするだけで確実に再作成できます。

c# multithreading concurrency

— ジョーギーキー
ソース

プロファイラーをコードに向けましたか？

— ティモゲーシュ

CLRとWindowsカーネルをプロファイリングしていない限り、プロファイリングでこの質問に答えることはできません（平均的なプログラマーにとっては簡単な作業ではありません）。

— イグビーラージマン

@JoeGeekyじゃあ、ここで私がやるべきことは+1と賛成だけだと思います！それは...など、彼らはすべての後に間接の同じレベルであることから奇妙なようで、とにかくプロセッサキャッシュに収まらなければならない

— マックス

FWITいくつかのスレッドを生成し、いくつかのタイマーを実行しました。クラス、シングルトン、lockedSingleton、およびdict <string、string>をインスタンス化しました。それぞれの最初のインスタンス化後、連続した実行は、任意のオブジェクトに対して約2000nsかかりました。辞書の実行速度は2倍遅く、コンストラクターコードが原因である可能性があります...それ自体がロックするよりも低速です。すべてのGC、スレッドキューのOS処理、およびその他のオーバーヘッドを考慮すると、この質問に本当に答えられるかどうかはわかりません。しかし、私の結果から、問題がシングルトンに関係しているとは思わない。MSDNのように実装されている場合ではなく、コンパイラの最適化を除外します。

— P.Brian.Mackey

@JoeGeeky-別の考え：キャッシュを使用すると間接性のレベルが追加されますか？頻繁にアクセスする場合、余分なポインタ参照（またはMSIL equiv）を追いかけると、間接的なローカルコピーに時間がかかる可能性があります。

— sdg

回答:

不変状態は、キャッシュラインを可変の何かと共有している可能性があります。この場合、近くの可変状態への変更は、コア間でこのキャッシュラインの再同期を強制する効果があり、パフォーマンスが低下する可能性があります。

— エイダンカリー
ソース

これfalse sharingはあなたが説明しているシナリオのように聞こえます。それを分離するには、L2キャッシュのプロファイルを作成する必要があります。幸いなことに、これらは参照タイプであるため、実際にこれが行われている場合、バッファスペースを追加することは選択肢になりません。

— JoeGeeky

辞書のキーとして使用するオブジェクトのメソッドEquals()とGetHashCode()メソッドに、予期しないスレッドに対応しない副作用がないことを確認します。ここではプロファイリングが大いに役立ちます。

おそらくあなたのキーが文字列であるなら、おそらくそこにある：文字列は不変オブジェクトのように振る舞うという噂がある。

辞書がシングルトンの代わりに通常の参照として使用するスレッドに辞書を渡して、問題が辞書の共有性にあるのか、それともシングルトン性にあるのかを確認します。（考えられる原因を排除します。）

また、その使用が驚くべき結果をもたらす場合に備えてConcurrentDictionary、通常の代わりに試してみDictionaryます。ConcurrentDictionaryあなたのレギュラーよりずっと良いか悪いかが判明した場合、目前の問題について推測することがたくさんありますDictionary。

上記のいずれも問題を指していない場合、パフォーマンスの低下は、ガベージコレクションスレッドと他のスレッド間の奇妙な競合によって引き起こされていると推測されます。ディクショナリ内のオブジェクトは、スレッドによってアクセスされている間、破棄されるかどうかが必要です。

— マイク・ナキス
ソース