問題タブ [memory-model]

• 私を困惑させるのはこれです。

ConcurrentHashMap の HashEntry の Java ドキュメント (jdk1.6.0_16)

...値フィールドは最終的なものではなく揮発性であるため、データ競合を介して読み取られたときに、非同期リーダーが初期値ではなく null を表示することは、Java メモリ モデルに関して合法です。これにつながる並べ替えが実際に発生する可能性はほとんどありませんが、Segment.readValueUnderLock メソッドは、同期されていないアクセス メソッドで null (事前に初期化された) 値が見られる場合のバックアップとして使用されます。

• ここに ConcurrentHashMap#Segment の get メソッドの実装があります

  /li>

• そして readValueUnderLock の

• 私の読書と理解に基づいて、すべてのスレッドは揮発性変数の最新の値を読み取ります。

• では、スレッドはいつ最初の null 値を読み取るのでしょうか? 特に、コンストラクターが完了する前に値が割り当てられる HashEntry では。(HashEntry の参照がそのコンストラクターを決してエスケープしないことにも注意してください。)

• ConcurrentHashMap（jdk1.6.0_16）のHashEntryの上記のJavaドキュメントを説明できる人がいます。そして、なぜ特別な予防ロックが必要なのですか?

Dalvik のメモリ モデルはJavaのメモリ モデルと同じですか? long参照変数と非プリミティブ変数の読み取りと書き込みがアトミックかどうかに特に関心がありますdoubleが、2 つのプラットフォームのメモリ モデルに違いがあるかどうかも知りたいです。

私は最近メモリモデルについて調べていて、これがどのように機能するかについてちょっと混乱していました.

http://cis.poly.edu/muller/CS623/weakmemory.htmを引用するには

プロセッサが新しい X を書き込んでから新しい Y を書き込んだ場合、その後 Y の読み取りと X の読み取りを実行する他のすべてのプロセッサは、新しい Y と新しい X、古い Y と新しい X、または古い X と古い X のいずれかにアクセスします。 Y: ただし、新しい Y と古い X にアクセスするプロセッサはありません。この強い順序付けの仮定は、かつては合理的でした。ただし、現在のコンピュータ メーカーは、プログラマがメモリの順序付けに依存しないことを推奨しています。これは、新しいメモリ管理システムが最適化のためにメモリ アクセスの順序を変更しようとするためです。メモリ要求の並べ替えが許可されているシステムは、弱順序メモリ システム (モデル) と呼ばれます。並べ替えを使用してパフォーマンスを向上させる方法を調べるには、次のアセンブラー コードを検討してください [2]。

ロケーション B が現在キャッシュにあり、ロケーション A がキャッシュされていないと仮定すると、A のロードは B よりも時間がかかります。A を待つ代わりに、CPU はキャッシュから B をフェッチして、B のレイテンシを隠します。したがって、CPU は実行できます。 Aが利用可能になり次第、追加。実行の強力な (シーケンシャル) メモリ モデル (つまり、A を最初にロードし、次に B をロードする必要がある) を緩和することで、パフォーマンスを向上させることができますが、並べ替えはソフトウェアに対して透過的ではない場合があります。以下のコード フラグメントを検討してください。これは、スピンロック セマフォの実装に使用できるコードの一部です [2]。

私の質問は、メモリ モデルが弱いと、プロセッサが新しい Y と古い X にアクセスできる可能性があるということです。同じメモリ (RAM) に書き込まれていませんか、それとも動作が異なりますか? あるプロセスが変数を変更し、その後別のプロセスがそれを読み取ると、最新の値が読み取られると思います。

私がよくわからないもう1つのことは、どのコンポーネントがメモリアクセスの並べ替えを許可しているかということです。私の仮定は、コンパイラが命令の並べ替えを許可されているということです。しかし、CPU はそれらを並べ替えることもできますか?

ありがとう

次のようなコードで、Proc1 と Proc2 が異なるプロセッサで同時に実行される場合、ThingVal2 が 5 以外の値 (ゼロなど) を取得することは可能ですか?

IA64 のような弱いモデルでは、Proc2 が ThingRef が変更されたと認識しても、Thing2 のフィールド X が変更されたと認識しない可能性が実際にあることを私は知っています。x86 または x64 で実行されている .Net アプリケーションにそのリスクは存在しますか? Proc1 が SimpleThing の新しいインスタンスを作成し、その X フィールドを 5 に設定し、ThingRef をそれを指すように設定した場合、危険を回避するにはそれで十分であるか、または新しい Thing がキャッシュ ラインに割り当てられる可能性があります。 Proc2 スレッドがアクセスした他の何かと共有されましたか?

マルチスレッド コードの一般的なパラダイムは、不変オブジェクトを構築し、それを指す可変参照を設定することです (おそらく Interlocked.CompareExchange を使用します)。x86/x64 では、スレッドに関係なく不変型を読み取ることは常に安全ですか?それとも問題を引き起こす可能性がありますか? 後者の場合、信頼できる動作を保証するためにvb.netで推奨される方法は何ですか?

また、そのような問題が発生しない方法でコードを実行する必要があることを指定する方法はありますか?

などの記事を::std::thread見::std::forwardたことがありますが、良い記事は見当たりませんでした::std::atomic。もちろん、標準化提案書もありますが、この機能を使いたいだけの人向けの適切なドキュメントは見たことがありません。

ありますか？どこで見つけることができますか？

x86 でのシーケンシャル コンシステント ロード操作に興味があります。

コンパイラーによって生成されたアセンブラーのリストを見る限り、x86 では単純なロードとして実装されていますが、私が知る限り、プレーンなロードはセマンティクスを取得することが保証されていますが、プレーンなストアは解放されることが保証されています。

シーケンシャル コンシステント ストアはロックされた xchg として実装され、ロードはプレーン ロードとして実装されます。私には奇妙に聞こえますが、これを詳しく説明していただけますか?

追加した

ロックされた xchg でストアが行われている限り、順次一貫性のあるアトミック ロードを単純な mov として実行できることがインターネットで見つかりましたが、証拠もドキュメントへのリンクもありませんでした。

次のJavaコードを使用します。

秘訣は、doSomeProcessing特定の条件下でのみ呼び出されることです。リストの初期化は非常に費用のかかる手順であり、まったく必要ない場合があります。

ダブルチェックのイディオムが壊れている理由についての記事を読んだことがあり、このコードを見たときは少し懐疑的でした。ただし、この例の制御変数はブール値であるため、私が知る限り、単純な書き込み命令が必要です。

someListまた、がとして宣言されfinal、同時リストへの参照を保持しwrites て いることに注意してくださいreads。ConcurrentLinkedQueueリストの代わりに単純なArrayListまたはLinkedList、として宣言されている場合でも、発生する必要はありませfinalん-の前に。writesreads

それで、上記のコードはデータの競合がないのですか？

Nvidia は、Cuda 4.0 により、プログラマーが CPU と GPU の間で統合メモリ モデルを使用できるようになると宣伝しているようです。これは、最高のパフォーマンスを得るために GPU と CPU でメモリを手動で管理する必要性に取って代わるものではありませんが、テスト、検証、および最適化 (GPU と CPU メモリを手動で管理する) が可能な、より簡単な実装が可能になりますか? コメントや意見を聞きたいです:)

ビュー モデルを介して UI にバインドされた (非揮発性) データがあり、何もロックせずにバックグラウンド スレッドからこのデータを更新し、PropertyChangedイベントをトリガーした場合、 UI がこの更新を確認することは保証されますか? もしそうなら、なぜですか？

CLRBindingWorker呼び出していることがわかりDispatcher.BeginInvoke、プロパティが UI スレッドから読み取られていることを確認できます。私が知りたいのは、UI スレッドでプロパティ値が常に「新鮮」であるかどうかです (たとえば、http://www.yoda.arachsys.com/csharp/threads/volatility.shtmlのようなシナリオが発生する可能性があるかどうか)。

以前の回答では、これが実際に当てはまることを示唆していましたが、説明はありません。

例：

セッターがロックで保護されているが、ゲッターの周りにロックがないプロパティがあるとします。

書き込みの同期（読み取りではない）に加えて、ロック、つまりMonitor.Exitにより、不安定な書き込みが発生するはずです。ここで、2つのスレッドAとBがあり、次のシーケンスが発生するとします。

1. Aはの現在の値を読み取りますMyProperty。
2. Bはに新しい値を書き込みますMyProperty。
3. MyPropertyAはの現在の値を再度読み取ります。

Q：Aは新しい値を確認できるようになりましたか？または、私たちのロックは、Bがタイムリーにメインメモリに書き込むことを保証しましたが、他のスレッドが新しい値を読み取ることは保証しませんでしたか？または、答えは、.Net 2+で実行しているか、「より弱い」ECMA実装で実行しているかによっても異なりますか？