コンストラクターにStoreStoreバリアーが必要ですか？

Question

ストアストアバリアをコンストラクタに配置する必要がありますか？

ここは例です。最初にglobal_f = f = r = 0とします。 1つのスレッドAがオブジェクトを作成し、フィールドに割り当て、グローバル変数に代入：

class Foo { 
    int x; 
    void Foo(int x) { 
     this.x = x; 
    } 
} 

f = new Foo(42); 
global_f = f; 

別のスレッドBは、グローバル変数から参照を取得し、そのフィールドを読み取ります。スレッドBはスレッドBからオブジェクト参照を読み出す

r = global_f.x; 

仮定すると実行が、どのような値は、それがrにXから読み取ることができますか？常に42かどうか？

私はC++ と Javaの動作に興味があります。 rは、メモリモデルを理解するためには42であることが保証されていません。

オブジェクトのフィールドが適切に初期化されるように、一般的なコンストラクタの最後にストアストアバリアを置くことができます。これは、C++とJavaの両方の落とし穴のようです。少なくともJavaの場合、最終フィールドにはすべて問題ありませんか？これは実際にはそれほど重要ではありません。なぜなら、少なくともx86とAMD64では、ストア・ストア・バリアがNOPであるからです。しかし、ARMやPOWERなどの他のアーキテクチャではそうではありません。

Answer 1

Javaの場合、はというフィールドを宣言しない限り、が42になるという保証はありません。

---

オブジェクトのフィールドが正しく初期化されていることを確認するために、我々は一般的には、コンストラクタの最後にストアストア障壁を置くことができます。これは、C++とJavaの両方の落とし穴のようです。

これはコメントではありません。しかし、逆の議論は、すべてのコンストラクタの終わりに暗黙のバリアを置くことは、様々な場合において不必要なパフォーマンス・ヒットをもたらすことである。例えばfがxへのアクセスが同期方式でガードされているマルチスレッドコードを

を公表していないマルチスレッドコードのシングルスレッドコード、

ため

• 。

JavaとC++のメモリモデルは、単純さとパフォーマンスの考慮点の間で妥協点があります。単純すぎる場合（つまり、落とし穴を設計するなど）、マルチスレッドコードを使用しても、人々が望む/必要とするスピードアップは得られません。