ロックフリー/ウェイトフリー アルゴリズムについて調査を行っているときに、誤った共有の問題に遭遇しました。もう少し掘り下げていくと、Folly のソース コード (Facebook の C++ ライブラリ) にたどり着きました。具体的には、このヘッダー ファイルとFOLLY_ALIGN_TO_AVOID_FALSE_SHARING
マクロの定義 (現在は 130 行目) にたどり着きました。一見して最も驚いたのは、値が128 (つまり、64 ではなく) であるということでした...
/// An attribute that will cause a variable or field to be aligned so that
/// it doesn't have false sharing with anything at a smaller memory address.
#define FOLLY_ALIGN_TO_AVOID_FALSE_SHARING __attribute__((__aligned__(128)))
私の知る限り、最新の CPU のキャッシュ ブロックの長さは 64 バイトであり、実際には、Intel からのこの記事を含め、これまでに見つけたすべてのリソースで、64 バイトのアラインメントとパディングについて説明されており、フォールス シェアリングを回避するのに役立ちます。
それでも、Facebook の人々は、必要に応じて、クラス メンバーを 128 バイトに調整およびパディングします。FOLLY_ALIGN_TO_AVOID_FALSE_SHARING
次に、の定義のすぐ上にある説明の始まりを見つけました。
enum {
/// Memory locations on the same cache line are subject to false
/// sharing, which is very bad for performance. Microbenchmarks
/// indicate that pairs of cache lines also see interference under
/// heavy use of atomic operations (observed for atomic increment on
/// Sandy Bridge). See FOLLY_ALIGN_TO_AVOID_FALSE_SHARING
kFalseSharingRange = 128
};
もう少し詳細が得られますが、まだいくつかの洞察が必要だと感じています. アトミック操作を多用すると、隣接するキャッシュ ラインの同期、またはそれらに対する RMW 操作がどのように相互に干渉するかについて興味があります。 誰かがこれがどのように起こる可能性があるかについて私に教えてもらえますか?