メモリバリア
コンパイラやオペレーティングシステムが用意しているアトミック操作のための組み込み関数やAPI関数を利用するなどして、リオーダーを抑制すべきである。
Java 1.5(Java 5とも呼ばれる)は新たなメモリモデルを採用しており、キーワードvolatileによって、ある種のハードウェアによる命令並べ替えとコンパイラによる並べ替えを防ぐことを保証している。一般的なアトミック操作にはjava.util.concurrent.atomicパッケージに用意されているクラス群を使う。C#のvolatileもJavaと類似の機能を持つ。一般的なアトミック操作にはSystem.Threading.Interlockedクラスを使用する。前述のようにC/C++標準規格のvolatileではサポートされていないが、Microsoft Visual C++コンパイラのvolatileでは独自拡張として同様の機能をサポートしている。Visual C++では、x86/x64に限り、バリア用の組み込み関数をサポートしているが、非推奨となっており、C++11で標準ライブラリに追加されたstd::atomic_thread_fenceおよびstd::atomic<T>を使うことが推奨されている。
そのような環境ではメモリバリアを必要とすることはないが、メモリ可視性がどうなっているかを可能な限り理解しておくことは重要である。ただし、メモリモデルの仕様が必ずしも文書化されていたり明確化されていたりするわけではない。
プログラミング言語のセマンティクス(意味論)が機械語の命令コードとは異なったレベルで抽象化されて定義されているように、プログラミング環境のメモリモデルはハードウェアのメモリモデルとは抽象化のレベルが異なっている。これらを区別して理解し、低レベルなメモリバリア命令と特定のプログラミング環境のメモリ可視性の意味が異なることを理解することが重要である。例えば、あるプラットフォームにおけるPthreadsの実装では、POSIX規格で要求されているものよりも強いメモリバリアを使用しているかもしれない。実装されたメモリ可視性を前提としてプログラムを作成すると、仕様上のメモリ可視性を前提としたプログラムよりも移植性が低くなる可能性がある。