問題タブ [memory-visibility]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
1 に答える
132 参照

c++ - CPUコアが1つしかない場合、スレッドごとのメモリ可視性の問題もありますか?

タイトルが変だと思うかもしれませんので、説明させてください。多くの場合、競合状態について教えている人はx == 0、スレッド 2 が既に認識しているのに、スレッド 1 は認識できると言っています。x=1;

私の質問は、同じコアでスケジュールされたスレッドに関するものです (非現実的ではありません。まだ 1 つのコアが組み込まれたシステムがあり、少なくとも理論的にはスレッドをコアにバインドする
可能性があります)。同じコア(X86、ARM)で(c)の他のスレッドと)前後に1つずつ...

0 投票する
3 に答える
715 参照

java - 並行 C++ プログラムでの可視性

Java では、別のスレッドからメンバーにアクセスするときにメンバーの可視性が保証されないことを知っています。

これは、アクセスしているスレッドがメンバーの盗まれた値を参照する可能性があることを意味します (キャッシュがまだメイン メモリにフラッシュされていないため)。

C++もそうなのかな?(C++11でも?)

もしそうなら、C++ でこの問題をどのように解決しますか? (Java では、synchronized キーワードを使用できます)。

0 投票する
2 に答える
139 参照

c# - BackgroundWorker は、バックグラウンド スレッドで行われたメモリの変更がメイン スレッドに表示されることを保証しますか?

BackgroundWorker を使用してアプリケーションのデータ構造を変更する場合、BackgroundWorker が完了すると (たとえば、RunWorkerCompleted イベント ハンドラー内で)、バックグラウンド スレッドで行われた変更がメイン (UI) スレッドに表示されるという保証はありますか? ボーナス ポイントについて: もしそうなら、これを保証するメカニズムは何ですか?

0 投票する
3 に答える
191 参照

multithreading - Perl ithreads :共有変数 - マルチプロセッサ カーネル スレッド - 可視性

perlthrtut の抜粋:

共有変数は、2 つ以上のスレッドが同時にそれを変更しようとしても、変数の内部状態が破損しないことを保証することに注意してください。ただし、次のセクションで説明するように、これを超える保証はありません。

マルチプロセッサ カーネル スレッドをサポートする Linux での作業。

すべてのスレッドが更新された共有変数の値を見るという保証はありますか? 上記のように perlthrtut のドキュメントを調べても、そのような保証はありません。

ここでの質問: それを保証するためにプログラムで何ができるでしょうか?

0 投票する
3 に答える
511 参照

java - volatile は必要ですか?

1 つのスレッド プロデューサーと別のコンシューマーがあると予想されるバイト キューがある場合:

このタイプのキューは同期を必要としません。
readIdx はリーダー スレッドによってのみ変更され、
writeIdx はライター スレッドによってのみ変更されます。

readIdx == writeIdx は、コンテンツがないことを意味します。
また、キューは最大 buf.length-1 バイトのデータしか使用できません。

1 つのスレッドだけが 1 つの整数状態の修飾子であるため、揮発性が必要ですか、または省略できますか?

thxフランク

0 投票する
2 に答える
297 参照

java - Java 並行プログラミングでの可視性の問題

本「Java Concurrency in Practice」で次の例に出くわしました。

さらに次のように述べられています。

ready の値がリーダー スレッドに表示されない可能性があるため、NoVisibility は永久にループする可能性があります。さらに奇妙なことに、NoVisibility はゼロを出力する可能性があります。これは、ready への書き込みが number への書き込みの前にリーダー スレッドに表示される可能性があるためです。これは、並べ替えと呼ばれる現象です。

並べ替えの問題は理解できますが、可視性の問題は理解できません。の値がreadyリーダースレッドに表示されないのはなぜですか? メイン スレッドが に値を書き込むとready、遅かれ早かれリーダー スレッドが実行され、 の値を読み取ることができますready。メインスレッドによって行われた変更がreadyリーダースレッドに表示されないのはなぜですか?

0 投票する
3 に答える
353 参照

java - 視認性保証

JCIP のセクション 16.3「初期化の安全性」の説明をいくつか読みましたが、まだ明確ではありません。セクションは次のように述べています

「さらに、適切に構築されたオブジェクトの final フィールド (final 配列の要素や final フィールドによって参照される HashMap の内容など) を介して到達できる変数は、他のスレッドからも見えることが保証されています。」

したがって、次の可変オブジェクトがあるとします。

次に、スレッド 1は次のように作成し、 c をThread2に渡します。

Thread2 (同時にではなく、1 ミリ秒後としましょう)、c の値を読み取ります。Thread2 が参照する可能性はありますか

乾杯

アップデート

クラスにゲッターがあることに混乱があることに気付きました。ソースコードを更新しています。これが明確になることを願っています。ご覧いただきありがとうございます。

//---------

//----

私の質問は次のとおりです。

a) Thread2が consumer () を呼び出すとき、name、cupsWon、netWorth は null、0、または 0.0 になる可能性がありますか? Container クラスのフィールドは最終的なものではないため、可視性が保証されないため、可能であると考えていました。

b) ただし、セクション 16.3 と「適切に構築されたオブジェクトの final フィールドを介して到達できる変数」に関するビットを読みましたが、これは、コンテナ c のインスタンスが final と宣言されているため、可視性が保証されていることを意味します?消費()?

最終的なコンテナ c = 新しいコンテナ("Ted Dibiasi", 10, 1000000);

c) Client クラスの Container への参照を volatile として宣言しても、参照に関連するため、フィールドの可視性の問題は解決されません。