問題タブ [volatile]

それぞれThreadが run メソッドに入り、呼び出された から値を取得することによって、スレッドに限定された一意のint変数を取得します。次に、それぞれが呼び出されるのを待ちます(最後のものがラッチに到達すると、すべてが解放されます)。ラッチが解放されると、各スレッドは、限定された値を共有されたに割り当てようとします。iAtomicIntegercountThreadCountDownLatchcdl1ThreadThreadsivolatileintbar

Thread1つを除くすべてが「バーがiに等しくない」と出力することを期待しますが、すべてThreadが「バーがiに等しい」と出力します。ええと、wtf はvolatile実際にそうしないとしますか?

それぞれがまったく同時にThreadの値を設定しようとするのは、意図的な意図です。bar

編集：

答えに照らして、コードを次のように変更しました。

変数の設定と読み取りの間に少しの時間が無駄になるようにするため。

これで、バーの同じ/異なる値で印刷が 50/50 になりました。

これまでのところ、以下から取得したものがあります

http://www.danielmoth.com/Blog/volatile-registrykey.aspx

これは機能しますが、かなり醜いです。より良い方法はありますか？

GetBuffer（）を呼び出すことにより、MemoryStreamオブジェクトのデータバッファーに直接データを書き込むコードが少しあります。また、PositionプロパティとSetLength（）プロパティを適切に使用および更新します。

このコードは99.9999％の確率で正しく機能します。文字通り。非常に多くの100,000回の反復ごとにのみ、それは吠えます。特定の問題は、MemoryStreamのPositionプロパティが適切な値ではなく突然ゼロを返すことです。

ただし、0をチェックし、PositionやLengthなどのMemoryStreamプロパティのログを別のメソッドに含む例外をスローするコードが追加されました。それらは正しい値を返します。同じメソッド内にロギングをさらに追加すると、このまれな状態が発生した場合、この特定のメソッド内では位置がゼロになるだけであることがわかります。

わかった。明らかに、これはスレッドの問題である必要があります。そして、おそらくコンパイラの最適化の問題です。

ただし、このソフトウェアの性質は、スケジューラーを使用した「タスク」によって編成されるため、いくつかの実際のO / Sスレッドのいずれかがいつでもこのコードを実行できますが、一度に複数のコードを実行することはできません。

したがって、通常、同じスレッドがこのメソッドに使用され続け、まれに別のスレッドが使用されることがあると思います。（スレッドIDをキャプチャして比較することにより、この理論をテストするためのアイデアをコーディングするだけです。）

次に、コンパイラの最適化により、別のスレッドが正しい値を取得することはありません。「古い」値を取得します。

通常、このような状況では、問題の変数に「volatile」キーワードを適用して、それが修正されるかどうかを確認します。ただし、この場合、変数はMemoryStreamオブジェクト内にあります。

他に何かアイデアはありますか？それとも、これは独自のMemoryStreamオブジェクトを実装する必要があることを意味しますか？

よろしくお願いいたします。ウェイン

編集：このメソッドへの呼び出しの総数をカウントし、ManagedThreadIdが最後の呼び出しと異なる回数をカウントするテストを実行しただけです。スレッドを切り替えるのはほぼ正確に50％の時間で、スレッドを交互に切り替えます。したがって、上記の私の理論はほぼ間違いなく間違っているか、エラーがはるかに頻繁に発生します。

編集：このバグはめったに発生しないため、バグが実際になくなったと感じる前に、バグなしで実行するのに1週間近くかかります。代わりに、問題の性質を正確に確認するために実験を実行することをお勧めします。

編集：現在、ロックは、MemoryStreamを使用する5つのメソッドのそれぞれでlock（）ステートメントを介して処理されます。

MyThread クラスのout変数は、このコードで volatile と宣言する必要がありますか、それとも ThreadTest クラスの変数の「揮発性」はstdout引き継がれますか?

は

と同じ

内部マップが異なるスレッドによってアクセスされる場合は?

または、このようなものが必要です:

それが「カスケードされた」マップではない場合、final と volatile は最終的に、すべてのスレッドが常に Map の正しい内容を確認できるようにするという同じ効果があります...しかし、Map 自体にマップが含まれている場合はどうなりますか?例のように...内部マップが正しく「メモリバリア」であることを確認するにはどうすればよいですか?

タンク！トム

2 つのスレッドと 1 つのオブジェクトがあるとします。1 つのスレッドがオブジェクトを割り当てます。

別のスレッドがオブジェクトを使用します:

変数 myObject は volatile として宣言する必要がありますか? いつ揮発性を使用するか、いつ使用しないかを理解しようとしていますが、これは私を困惑させています。2 番目のスレッドが古いオブジェクトへの参照をローカル メモリ キャッシュに保持している可能性はありますか? そうでない場合、なぜですか？

どうもありがとう。

特定の問題、自己回答、およびそれに対するコメントに続いて、それが適切な解決策であるか、回避策/ハックであるか、または単に間違っているかを理解したいと思います。

具体的には、コードを書き直しました。

として：

volatileポインタへの修飾子付き。

T私の状況のようintに扱うことが理にかなっていると仮定しましょう。参照を介したこのアクセスは、volatileポインターエイリアシングの問題を解決しますか？

参考までに、仕様から：

[注：オブジェクトの値は実装で検出できない手段によって変更される可能性があるため、volatileは、オブジェクトが関与する積極的な最適化を回避するための実装へのヒントです。詳細なセマンティクスについては、1.9を参照してください。一般に、volatileのセマンティクスは、C++でもCと同じであることが意図されています。— end note]

編集：

上記のコードは、少なくともGCC4.5で私の問題を解決しました。

私volatileはJavaのキーワードについてかなり良い考えを持っていると思いますが、いくつかのコードをリファクタリングすることを考えていて、それを使うのは良い考えだと思いました.

基本的にDBキャッシュとして機能するクラスがあります。データベースから読み取った一連のオブジェクトを保持し、それらのオブジェクトの要求を処理し、(タイムアウトに基づいて) ときどきデータベースを更新します。骸骨はこちら

そのため、loadMappingsFromDB は待ち時間の長い操作になる可能性があり、それは受け入れられないという懸念があります。そのため、最初は、キャッシュの起動時にスレッドをスピンアップし、それをスリープさせて、バックグラウンドでキャッシュを更新できると考えていました。しかし、その後、クラス (またはマップ) を同期する必要があります。そして、すべてのキャッシュアクセスを遅くするために、時折大きな一時停止を行うだけです。

それから私はなぜ使わないのかと思いましたvolatile

マップ参照を揮発性として定義できます

そして、get（またはマッピング変数を使用する他の場所）で、参照のローカルコピーを作成します：

バックグラウンドスレッドは一時テーブルにロードされ、クラス内の参照を交換します

このアプローチは理にかなっていますか？それは実際にスレッドセーフですか？

それができることはわかったが、その趣旨がよくわからない。

volatileインスタンス変数の読み取り/書き込みが2つあり、ロックを解除するオーバーヘッド（または潜在的なデッドロックのリスク）が必要ない場合は、インスタンス変数を使用することがあります。たとえば、タイマースレッドは、あるクラスでゲッターとして公開されているintIDを定期的に更新します。

私の質問：JLSが32ビット読み取りがアトミックであることを保証するだけだとすると、揮発性のlongを使用することに意味はありますか？（つまり、64ビット）。

警告volatile： overの使用synchronizedは事前最適化の場合であると言って返信しないでください。いつどのように使うかはよく知っていますが、望ましいsynchronized場合もあります。volatileたとえば、シングルスレッドアプリケーションで使用するSpring Beanを定義する場合volatile、Springコンテキストがメインスレッドで各Beanのプロパティを初期化する保証がないため、インスタンス変数を優先する傾向があります。