問題タブ [memory-model]

VolatileRead/VolatileWriteメソッド (Reflector を使用)の実装を調べていますが、何かに戸惑っています。

これは VolatileRead の実装です。

「アドレス」の値を読み取った後にメモリバリアが配置されるのはなぜですか? 逆にいいんじゃないの？（値を読み取る前に配置するため、「アドレス」への保留中の書き込みは、実際の読み取りを行うまでに完了します。同じことが、値の割り当ての前にメモリバリアが配置される VolatileWrite にも当てはまります。なぜですか？ ? また、これらのメソッドにNoInlining属性があるのはなぜですか? インライン化するとどうなるでしょうか?

そこで私は、来たる C++0x 標準の一部であるメモリ モデルについて読んでいました。ただし、コンパイラーが許可されていること、特に投機的なロードとストアに関するいくつかの制限については、少し混乱しています。

まず、関連するもののいくつか：

C++0x のスレッドとメモリ モデルに関する Hans Boehm のページ

Boehm、「スレッドはライブラリとして実装できない」

Boehm と Adve、「C++ 同時実行メモリ モデルの基礎」

Sutter、「Prism: Microsoft ネイティブ コード プラットフォーム向けの原理ベースのシーケンシャル メモリ モデル」、N2197

Boehm、「同時実行メモリ モデル コンパイラの結果」、N2338

現在、基本的な考え方は本質的に「データ競合のないプログラムの順次整合性」です。これは、プログラミングの容易さと、コンパイラとハードウェアの機会を最適化できるようにすることとの間の適切な妥協点のようです。データ競合は、異なるスレッドによる同じメモリ ロケーションへの 2 つのアクセスが順序付けられておらず、そのうちの少なくとも 1 つがメモリ ロケーションに格納され、そのうちの少なくとも 1 つが同期アクションではない場合に発生するように定義されています。これは、共有データへのすべての読み取り/書き込みアクセスが、ミューテックスやアトミック変数の操作など、何らかの同期メカニズムを介して行われる必要があることを意味します (まあ、専門家のみが緩和されたメモリ順序でアトミック変数を操作することは可能ですが、デフォルトではシーケンシャルな一貫性のため)。

これに照らして、通常の共有変数に対するスプリアスまたは投機的なロード/ストアに関する制限について混乱しています。たとえば、N2338 には次の例があります。

コンパイラが変換することを許可されていない

y == 2 の場合、x への偽の書き込みがあり、別のスレッドが x を同時に更新している場合に問題になる可能性があるためです。しかし、なぜこれが問題なのですか？これはデータ競合であり、とにかく禁止されています。この場合、コンパイラは x に 2 回書き込むことで状況を悪化させますが、1 回の書き込みでもデータ競合には十分ですよね? つまり、適切な C++0x プログラムは x へのアクセスを同期する必要があります。その場合、データ競合はなくなり、スプリアスストアも問題になりませんか?

N2197 の例 3.1.3 と他のいくつかの例についても同様に混乱していますが、上記の問題の説明でそれも説明できるかもしれません。

編集：答え：

投機的ストアが問題となる理由は、上記の switch ステートメントの例では、y != 2 の場合に限り x を保護するロックを条件付きで獲得することをプログラマーが選択した可能性があるためです。元のコードであるため、変換は禁止されています。同じ議論が N2197 の例 3.1.3 にも当てはまります。

Java メモリ モデルでは、a の書き込みintはアトミックであることが義務付けられています。つまり、あるスレッドで値 (4 バイトで構成される) を書き込み、別のスレッドでそれを読み取ると、すべてのバイトを取得するか、まったく取得しませんが、2 つの新しいバイトと2古いバイトなど。

については保証されませんlong。0x1122334455667788ここで、前に保持されている変数に書き込むと、0別のスレッドで0x112233440000000orが読み取られる可能性があります0x0000000055667788。

現在、仕様では、オブジェクト参照が int または long サイズのいずれかである必要はありません。型の安全性の理由から、アトミックに書き込まれることが保証されていると思いますが、64 ビット VM では、これらの参照は 64 ビット値 (単なるメモリ アドレス) である可能性があります。

ここに私の質問があります：

• これをカバーするメモリモデルの仕様はありますか (私は見つけていません)?
• 長時間書き込みは 64 ビット VM でアトミックである疑いがありますか?
• VM は参照を 32 ビットにマップする必要がありますか?

よろしく、ステフェン

次のコードがあるとします。

せいだ！主な質問は、なぜ... CPU が flag1 = true; で操作を並べ替えると思います。および if(flag2) ステートメントですが、変数 flag1 および flag2 は揮発性フィールドとしてマークされています...

Javaでの相互排除のためのPetersonアルゴリズムの実装例はありますか?

現在のC++0x ドラフトでは、セクション 29.3.9 および 29.3.10 の 1111 ～ 1112 ページに次の例のように記載されています。

r1 = r2 = 1各スレッドの操作が緩和され、無関係なアドレスに送信されるため、結果は可能です。ここで、私の質問は、次の (同様の) 例の考えられる結果についてです。

r1 = r2 = 1この場合、結果はありえないと思います。可能であれば、y のロードは y へのストアと同期します (つまり、前に発生します)。x と同様に、x のロードは x へのストアの前に発生します。ただし、y のロードは、x へのストアの前に順序付けられます (したがって、前に発生します)。これにより、循環的な事前発生関係が作成されますが、これは許可されていないと思います。

Javaメモリモデルで私を悩ませているものがあります（すべてを正しく理解していても）。2 つのスレッド A と B がある場合、A と B の両方が同じモニターで同期しない限り、B が A によって書き込まれた値を参照できるという保証はありません。

スレッド間のキャッシュの一貫性を保証するシステム アーキテクチャでは、問題はありません。ただし、アーキテクチャがハードウェアのキャッシュ コヒーレンシをサポートしていない場合、これは基本的に、スレッドがモニターに入るたびに、以前に行われたすべてのメモリ変更をメイン メモリにコミットし、キャッシュを無効にする必要があることを意味します。そして、それは全体である必要がありますこれは、モニターが保護するメモリ内の変数に関する情報を持っていないためです。しかし、それは、頻繁に同期する必要があるアプリケーションのパフォーマンスに確実に影響を与えます (特に、実行時間の短いジョブを含むジョブ キューなど)。では、Java は、ハードウェア キャッシュ コヒーレンシのないアーキテクチャでも十分に機能するのでしょうか? そうでない場合、メモリ モデルが可視性についてより強力な保証をしないのはなぜですか? 言語がモニターによって保護されている情報を必要とする場合、より効率的ではないでしょうか?

ハードウェアでキャッシュの一貫性が保証されている場合でも、メモリ モデルは両方の世界で最悪の事態をもたらします。同期が絶対に必要であり、一方で、一貫性のないアーキテクチャ (フル キャッシュ フラッシュ) ではパフォーマンスが低下します。では、より厳密にする (モニターによって保護されている情報を要求する) べきではないか、潜在的なプラットフォームをキャッシュ コヒーレント アーキテクチャに制限するべきではないでしょうか?

今のままでは、あまり意味がありません。この特定のメモリ モデルが選択された理由を説明できる人はいますか?

編集：振り返ってみると、strictとloseの使用は悪い選択でした。保証が少ない場合に「厳密」を使用し、反対の場合に「失う」を使用しました。混乱を避けるために、より強いまたはより弱い保証の観点から話す方がおそらく良いでしょう.

複数のスレッドによってアクセスされているミューテックスによって保護されていない変数 (おそらく volatile とマークされている) が最終的に一貫するという一般的な標準 (ISO C または C++、または POSIX/SUS 仕様のいずれか) による保証はありますか?割り当てられている場合は？

具体的な例として、2 つのスレッドが変数 v を共有し、初期値がゼロであるとします。

Thread 1: v = 1

Thread 2: while(v == 0) yield();

Is thread 2 guaranteed to terminate eventually? Or can it conceivably spin forever because the cache coherency never kicks in and makes the assignment visible in thread 2's cache?

I'm aware the C and C++ standards (before C++0x) do not speak at all about threads or concurrency. But I'm curious if the C++0x memory model, or pthreads, or anything else, guarantees this. (Apparently this does actually work on Windows on 32-bit x86; I'm wondering if it's something that can be relied on generally or if it just happens to work there).

Pythonスレッドは、Javaと同様に、メモリの可視性とステートメントの並べ替えの問題を明らかにしますか？多くの人がマルチスレッドのPythonコードを書いているにもかかわらず、「Pythonメモリモデル」などへの参照が見つからないため、これらの落とし穴はここには存在しないと思います。たとえば、volatileキーワードはありません。しかし、たとえば、あるスレッドの変数の変更が他のすべてのスレッドにすぐに表示されることは、どこにも明示的に述べられていないようです。

たぶん、これはすべてPythonプログラマーにとって非常に明白ですが、恐ろしいJavaプログラマーとして、私は少し余分な安心感が必要です:)

私はJavaスレッドに不慣れで、最近メモリモデルを読み始めたばかりです。私の理解では、現状のJavaメモリモデルにより、コンパイラは最適化を行うことができます。

これはマルチスレッドコードと同期を複雑にする可能性がありますが、私の質問はもっと単純なものです。2つのステートメントは相互に依存していないため、この例を見てください。コンパイラがtryステートメントのコードの順序を変更して、チェックを破る可能性はありますか？