2

問題の背景

問題のコードは、C++ の実装に関連しています。特定の重要な実装のために使用するコードベースがありますasm volatile ("mfence":"memory")。

メモリバリアに関する私の理解は -

  • 命令セットの完全な/順序付けられた実行を保証するために使用されます。
  • これは、従来のスレッド同期の問題を回避するのに役立ちます- Wiki リンク。

質問

PS :

  • このコードではasm volatile ("mfence":"memory")、10 ～ 15 行の C++ コード (メンバー関数) の後に of を使用しています。したがって、私の疑問は-メモリ同期のミューテキスト実装により、ユーザーが実装したコード(MBの範囲)でMBよりも優れたパフォーマンスが得られる可能性があることです。

  • クアッド コア プロセッサを搭載した SUSE Linux 10、2.6.16.46、smp#1、x64_86 を使用しています。

4

1 に答える 1

2

pthreadミューテックスは、メモリフェンス命令よりも遅いことが保証されています（プラットフォームに完全に依存するため、どれだけ遅いかはわかりません）。その理由は単純に、posix ミューテックスに準拠するためには、メモリ保証が含まれていなければならないからです。posixミューテックスには強力なメモリ保証があるため、そのようなフェンスなしでどのように実装されるかわかりません*。

実用的なアドバイスが必要な場合は、多くの場所でミューテックスの代わりにフェンスを使用しており、両方の時間を頻繁に測定しています。pthread_mutexes は、単なる生のメモリ フェンスと比較して、Linux では非常に低速です (もちろん、それらはより多くのことを行うため、実際に比較しているものに注意してください)。

ただし、特定のアトミック操作、特に C++11 の操作は、フェンス全体を使用するよりも高速になる可能性があり、確実に高速になることに注意してください。この場合、コンパイラ/ライブラリはアーキテクチャを理解しており、メモリ保証を提供するために完全なフェンスを使用する必要はありません。

また、ロック自体の非常に低レベルのパフォーマンスについて話していることに注意してください。ナノ秒レベルまでプロファイリングする必要があります。

*特定のタイプのメモリを無視し、より寛大なロック実装を選択するミューテックス システムを想像することは可能です (通常のメモリの順序保証に依存し、特別にマークされたメモリを無視するなど)。ただし、そのような実装は有効ではないと主張します。

于 2012-04-30T12:03:38.853 に答える