問題タブ [happens-before]

Java のメモリ モデルは、ルールを強制する「前に発生する」関係に基づいていますが、キャッシュの無効化に関して仮想マシンの実装を最適化することもできます。

たとえば、次の場合:

スレッド A が呼び出され、スレッド B が内部でmethod()取得を試みた場合、ロックを解放する前にスレッド A がすべての変数に対して行ったすべての変更をスレッド B が監視する必要があります。ロック」セクション。lockAmethod2()lockA

一方、method3()別のロックを使用し、事前発生関係を強制しません。これにより、最適化の機会が生まれます。

私の質問は、仮想マシンがこれらの複雑なセマンティクスをどのように実装するかということです。キャッシュが不要な場合、キャッシュの完全なフラッシュを回避しますか?

どの変数がどの時点でどのスレッドによって変更されたかをどのように追跡して、必要なキャッシュラインだけをメモリからロードするのでしょうか?

Java は、ドキュメントによると、同時実行パッケージで Lock オブジェクトを提供します。provides more extensive locking operations than can be obtained using synchronized methods and statements.

相互排除に加えて、同期されたメソッド/ブロックは、1 つのスレッドによって変数に加えられた変更が他のスレッドに確実に表示されるようにする先行発生関係を強制します。

Lock オブジェクトを使用すると、この関係が発生しますか? すべてのプラットフォームの同期ブロックの場合のように、監視は保証されますか?

私はC# コードの Java ポートを試していましたgetfieldが、オブジェクト フィールドにアクセスするたびに javac 1.8.0_60 がオペコードを発行していることに驚きました。

Javaコードは次のとおりです。

javap で報告されているように、javac 1.8.0_60 は次のバイトコードを生成します。

およびフィールドがアクセスされるgetfieldたびに、コンパイラによってオペコードが発行されたことに注意してください。signbits

JLS8 の §17.4.5、Happens-before Order を読んで、フィールドとフィールドがアクセスされるgetfieldたびにオペコードを発行する必要がある理由がわかりません(初回以外)。signbits

Java コンパイラが 2 つのgetfieldオペコードのみを発行し、その時点で表示されているフィールドの値をフレーム ローカル変数に保存することは合法でしょうか?

「スレッドがデータを読み取る場合、データの可視性を保証する書き込みから読み取りまでのハプニング ビフォア エッジがあります」

私は私の学習から知っています：

1. volatile は、すべての読み取り/書き込みが、キャッシュまたはレジスタだけではなく、メモリ内にあることを保証します。
2. volatile は並べ替えを保証します。つまり、setOnce() メソッドで data = o をスケジュールできるのは、if(ready) throw... の後、ready = true; の前だけです。これにより、get() で ready = true の場合、データは o でなければならないことが保証されます。

私の混乱は

1. スレッド 1 が setOnce() にあるときに、data = o; の後に到達する可能性はありますか? 準備ができている前に = true; 同時に、スレッド 2 が get() に実行され、read ready が false になり、null が返されます。そして、thead 1 は ready = true を続けます。このシナリオでは、スレッド 1 でデータに新しい値が割り当てられていても、スレッド 2 は新しい「データ」を認識しませんでした。

2. get() は同期されていません。つまり、同期ロックは setOnce() を保護できません。これは、スレッド 1 が get() を呼び出して、変数 Ready のデータにアクセスするためにロックを取得する必要がないためです。そのため、スレッドはデータの最新の値を確認できるとは限りません。これにより、ロックは同期されたブロック間の可視性のみを保証することを意味します。1 つのスレッドが同期ブロック setOnce() を実行していても、別のスレッドは引き続き get() に入り、ブロックせずに Ready とデータにアクセスでき、これらの変数の古い値が表示される場合があります。

3. get() で、ready = true の場合、データは o でなければなりませんか? このスレッドは、データの可視性が保証されているということですか? データは揮発性でも get() 同期でもないと思います。このスレッドはキャッシュ内の古い値を参照できますか?

ありがとう！

Java で事前発生関係を確立するには、同期ブロックとメソッド、volatile キーワードの 2 つの方法があることを私は知っています。（私が正しければ、最終フィールドでは機能しません）。私の質問は次のとおりです。並行パッケージのアトミック変数は同じように動作しますか? 事前発生は彼らによって確立できますか?

この番組か

終了することが保証されているか、デッドロックする可能性がありますか? を使用するとどうなりますmem_ord = std::memory_order_relaxedか？storeに-ing している間、ロックを保持する他の理由はありatomic<int>ますか? cppreference.comは、 のロックガードのある行のコメントを外す必要があることを要求していnotify_threadます。

（任意のメモリ順序で）通知store の前に発生し、 の（潜在的な）ウェイクアップの前に発生しwait、の前に発生することを期待しますload。notify-thread（もちろん、条件変数の前に終了する可能性があるため、「潜在的なウェイクアップ」と言いwaitます。その場合、ウェイクアップはありません）。したがって、（メモリの順序に関係なく）ロックガードのある行のコメントを外す必要はないと思います。

UNIX ライクな OS のシステム コールは再入可能です (つまり、複数のシステム コールを並行して実行できます)。C/C++11 の事前発生関係という意味で、これらのシステム コールの順序に関する制約はありますか?

たとえば、3 つのスレッド (疑似コード) を持つ次のプログラムを考えてみましょう。

ここで、xとyが共有の場所であり、すべてのloadとstoreの順序が緩和されているとします。(注: アトミック アクセスが緩和されている場合、競合はバグとは見なされません。C/C++11 セマンティクスの意味では意図的store x 1なものです。) このプログラムは終了する可能性があります。(1) コンパイラがandを並べ替えてからstore y 2、(2) 実行する可能性があるためです。 store y 2、store y 1、store x 2、そしてstore x 1、(3) スレッド 3 はx = 1とy = 1を同時に読み取ることができます。

次のプログラムも終了する可能性があるかどうかを知りたいです。ここでは、いくつかのシステム コールsyscall1()&syscall2()がそれぞれスレッド 1 と 2 に挿入されています。

プログラムを終了できないようです。ただし、呼び出されるシステム コールの順序の制約がない場合、このプログラムは終了する可能性があると思います。これが理由です。syscall1()とはシリアルsyscall2()化されておらず、並列で実行される可能性があるとします。syscall1()その後、コンパイラは、 andのセマンティクスを完全に認識しているため、&と をsyscall2()並べ替えることができます。store x 1syscall1()store y 2

そこで、異なるスレッドによって呼び出されるシステム コールの順序に関する制約があるかどうかを尋ねたいと思います。可能であれば、この種の質問の信頼できる情報源を知りたいです。