記憶の壁

コンピューティングにおいて、メモリ バリア(メンバ、メモリ フェンス、またはフェンス命令とも呼ばれる) は、バリア 命令の一種であり、バリア命令の前後に発行されるメモリ操作に対して、中央処理装置(CPU) またはコンパイラが順序制約を強制するようにします。これは通常、バリアの前に発行された操作が、バリアの後に発行された操作の前に実行されることが保証されることを意味します。

メモリ バリアが必要なのは、最近の CPU のほとんどが、アウトオブオーダー実行につながるパフォーマンス最適化を採用しているためです。メモリ操作 (ロードとストア) の順序変更は、通常、単一の実行スレッド内では気付かれませんが、慎重に制御しないと、並行プログラムやデバイス ドライバーで予期しない動作を引き起こす可能性があります。順序制約の正確な性質はハードウェアに依存し、アーキテクチャのメモリ順序モデルによって定義されます。一部のアーキテクチャでは、異なる順序制約を適用するために複数のバリアが用意されています。

メモリ バリアは通常、複数のデバイスで共有されるメモリ上で動作する低レベルのマシン コードを実装するときに使用されます。このようなコードには、マルチプロセッサシステム上の同期プリミティブ やロックフリーデータ構造、およびコンピュータ ハードウェアと通信するデバイス ドライバーが含まれます。

プログラムがシングル CPU マシンで実行される場合、ハードウェアは、すべてのメモリ操作がプログラマによって指定された順序 (プログラム順序) で実行されたかのようにプログラムが実行されることを確認するために必要な記録を実行するため、メモリ バリアは必要ありません。ただし、マルチプロセッサ システム内の他の CPU やメモリ マップされた周辺機器など、複数のデバイスでメモリが共有されている場合は、順序外アクセスによってプログラムの動作が影響を受ける可能性があります。たとえば、2 番目の CPU は、最初の CPU によって行われたメモリ変更を、プログラム順序とは異なる順序で認識する場合があります。

プログラムは、マルチスレッド化可能なプロセス (つまり、ハードウェア スレッドではなく、 pthreadsなどのソフトウェア スレッド) を介して実行されます。異なるプロセスはメモリ空間を共有しないため、この説明は、それぞれが異なるプロセス (したがって、異なるメモリ空間) で実行される 2 つのプログラムには適用されません。これは、単一のプロセス (つまり、複数のソフトウェア スレッドが単一のメモリ空間を共有する単一のメモリ空間) で実行される 2 つ以上の (ソフトウェア) スレッドに適用されます。マルチコア プロセッサでは、単一のプロセス内の複数のソフトウェア スレッドが同時に実行される場合があります。

マルチコア プロセッサ上で実行される次のマルチスレッド プログラムは、このような順序外実行がプログラムの動作にどのような影響を与えるかを示す例です。

最初は、メモリ位置xとのf両方に値 が保持されます0。プロセッサ #1 で実行されているソフトウェア スレッドは、 の値がfゼロの間ループし、その後 の値を出力しますx。プロセッサ #2 で実行されているソフトウェア スレッドは、 の値42を に格納しx、その後 の値1を に格納しますf。2 つのプログラム フラグメントの疑似コードを以下に示します。

プログラムのステップは、個々のプロセッサ命令に対応します。

PowerPCプロセッサの場合、このeioio命令はメモリフェンスとして、プロセッサによって開始されたロードまたはストア操作がメインメモリに対して完全に完了していることを保証し、その後にプロセッサによって開始されたロードまたはストア操作がメインメモリにアクセスする前に完了します。^{[1] [2]}

スレッド #1 コア #1:

 while ( f == 0 ); // ここでメモリフェンスが必要print x ;   
 
  

スレッド #2 コア #2:

 x = 42 ; // ここでメモリフェンスが必要f = 1 ;  
 
   

print 文は常に数値「42」を出力すると予想されるかもしれませんが、スレッド #2 のストア操作が順序どおりに実行されなかった場合、 が の前にf更新される可能性があり、print 文は「0」を出力する可能性があります。同様に、スレッド #1 のロード操作は順序どおりに実行され、がチェックされる前にが読み取られる可能性があり、この場合も print 文は予期しない値を出力する可能性があります。ほとんどのプログラムでは、これらの状況はどちらも許容されません。 の新しい値がの値の変更時またはそれ以前に他のプロセッサから見えるようにするために、スレッド #2 が に割り当てる前にメモリバリアを挿入する必要があります。もう 1 つの重要な点は、 の値の変更を確認する前に の値が読み取られないようにするために、スレッド #1 が にアクセスする前にもメモリバリアを挿入する必要があることです。 xx ffxfxxf

もう 1 つの例は、ドライバーが次のシーケンスを実行する場合です。

 ハードウェアモジュール用のデータを準備する// ここでメモリフェンスが必要となり、ハードウェアモジュールがデータを処理するようにトリガーする     
 
        

プロセッサのストア操作が順序どおりに実行されない場合、データがメモリ内で準備される前にハードウェア モジュールがトリガーされる可能性があります。

別の例（実際の現場で発生する重要な例）については、ダブルチェック ロックを参照してください。

マルチスレッド プログラムでは通常、 Javaや.NETなどの高水準プログラミング環境、またはPOSIX スレッドやWindows APIなどのアプリケーション プログラミング インターフェイス(API) によって提供される同期プリミティブが使用されます。ミューテックスやセマフォなどの同期プリミティブは、並列実行スレッドからのリソースへのアクセスを同期するために提供されます。これらのプリミティブは通常、期待されるメモリ可視性セマンティクスを提供するために必要なメモリ バリアを使用して実装されます。このような環境では、通常、メモリ バリアを明示的に使用する必要はありません。

メモリ バリア命令は、ハードウェア レベルでのみ、順序変更の影響に対処します。コンパイラーは、プログラム最適化プロセスの一環として命令を順序変更することもあります。並列プログラムの動作への影響はどちらの場合も同様ですが、一般に、複数の実行スレッドで共有される可能性のあるデータに対しては、コンパイラーの順序変更の最適化を抑制するために別の対策を講じる必要があります。

CおよびC++では、volatileキーワードは、 C および C++ プログラムがメモリマップ I/O に直接アクセスできるようにするために使用されました。メモリマップ I/O では通常、ソースコードで指定された読み取りと書き込みが、省略なしで指定されたとおりの順序で実行される必要があります。コンパイラによる読み取りと書き込みの省略または順序変更は、プログラムとメモリマップ I/O によってアクセスされるデバイス間の通信を切断します。C または C++ コンパイラは、揮発性メモリ位置からの読み取りと書き込みを省略することはできません。また、同じ揮発性位置 (変数) に対する他のアクションと比較して読み取り/書き込みを順序変更することもできません。キーワードvolatile は、キャッシュの一貫性を強制するメモリバリアを保証するものではありません。したがって、 volatileのみを使用するだけでは、すべてのシステムおよびプロセッサでスレッド間通信に変数を使用するのに十分ではありません。^[3]

C11 および C++11 より前の C および C++ 標準では、複数のスレッド (または複数のプロセッサ) には対応していません^[4]。そのため、volatileの有用性はコンパイラとハードウェアに依存します。volatileは、ソース コードで指定された順序どおりに volatile 読み取りと volatile 書き込みが行われることを保証しますが、コンパイラがコードを生成する (または CPU が実行順序を変更する) と、volatile 読み取りまたは書き込みが非 volatile 読み取りまたは書き込みに対して順序変更される可能性があり、そのため、スレッド間フラグまたはミューテックスとしての有用性が制限されます。

• ロックフリーおよび待機フリーのアルゴリズム
• メルトダウン（セキュリティ脆弱性）

• メモリバリア: ソフトウェアハッカーのためのハードウェアの視点
• 複数の種類の CPU における Linux カーネルのメモリ バリアの問題
• Linux カーネルのメモリバリアに関するドキュメント
• Oracle Solaris Studio 12 Update 2 を使用したマルチスレッド アプリケーションでのメモリ順序の処理: パート 1、コンパイラ バリア
• Oracle Solaris Studio 12 Update 2 を使用したマルチスレッド アプリケーションでのメモリ順序の処理: パート 2、メモリ バリアとメモリ フェンス
• ユーザー空間 RCU: メモリバリアの動物園