問題タブ [volatile]

重要な編集2つの割り当てが行われているスレッドの「前に起こる」について知っています。私の質問は、 「a」がまだnullである間に、別のスレッドが「b」をnull以外で読み取る可能性があるかどうかです。したがって、以前にsetBothNonNull（...）を呼び出したスレッドと同じスレッドからdoIt（）を呼び出している場合、NullPointerExceptionをスローすることはできません。しかし、setBothNonNull（...）を呼び出すスレッドとは別のスレッドからdoIt（）を呼び出す場合はどうなるでしょうか。

この質問はvolatileキーワードとvolatile保証に関するものであることに注意してください。キーワードに関するものではありません（したがって、解決する問題がないため、「同期を使用する必要があります」と答えないでください。単に保証synchronizedを理解したいだけです。volatile（または保証の欠如）アウトオブオーダー実行に関して）。

volatileコンストラクターによってnullに初期化される2つの文字列参照を含むオブジェクトがあり、2つの文字列を変更する方法は1つしかないとします。つまり、 setBoth（...）を呼び出し、後でそれらの参照を非に設定することしかできません。 null参照（コンストラクターのみがそれらをnullに設定できます）。

たとえば（これは単なる例であり、まだ質問はありません）：

setBothNoNull（...）では、非nullパラメータ「a」を割り当てる行が非nullパラメータ「b」を割り当てる行の前に表示されます。

次に、これを行うと（もう一度、質問はありません。質問は次に来ます）：

アウトオブオーダー実行のためにNullPointerExceptionが発生する可能性があることを理解していますか？

言い換えると、null以外の「b」を読み取ったためにnull以外の「a」を読み取るという保証はありませんか？

アウトオブオーダー（マルチ）プロセッサとvolatile動作方法により、「a」の前に「b」を割り当てることができますか？

volatile書き込みに続く読み取りは常に最後に書き込まれた値を参照することを保証しますが、ここには順序が正しくない「問題」がありますか？volatile（繰り返しになりますが、「問題」は、問題を解決するためではなく、キーワードとJavaメモリモデルのセマンティクスを理解しようとすることを目的としています）。

揮発性と可変性の違いについて質問があります。私は、2つの両方がそれが変更される可能性があることを意味していることに気づきました。ほかに何か？それらは同じものですか？違いは何ですか？それらはどこに適用できますか？なぜ2つのアイデアが提案されているのですか？それらを別の方法で使用する方法は？

どうもありがとう。

volatileC ++のメンバー関数の目的は何ですか？

私は同様の質問への回答を読んできましたが、まだ少し混乱しています...アベルには素晴らしい回答がありましたが、これは私が確信していない部分です:

...変数 volatile を宣言すると、アクセスごとに volatile になります。この動作を他の方法で強制することは不可能であるため、volatile を Interlocked に置き換えることはできません。これは、他のライブラリ、インターフェイス、またはハードウェアが変数にアクセスしていつでも更新できるシナリオ、または最新バージョンが必要なシナリオで必要になります。

Interlockedすべてのスレッドに対するアトミック操作の可視性は保証されますか?それとも、変更の可視性を保証するために値にキーワードを使用する必要がありvolatileますか?

これが私の例です：

更新:
私はスポーツが苦手で、元の例を変更したので、ここにもう一度示します。

次のコードを検討してください。

これにより、次のエラーが発生しg++ます。

p私の意図は、揮発性にしたいということでした。ただし、の値を読み取った後は、アクセスが揮発性であるpかどうかは関係ありません。なぜ揮発性であると宣言vする必要があるのですか？v

もちろん、これは架空のコードです。p実際の状況では、それはメモリの場所を指していると想像できますが、外部で変更されているので、後で外部で変更されたとしても、その時点で指してvいた場所を指したいと思います。したがって、揮発性ですが、そうではありません。pv = pppv

ちなみに、これがCとC ++の両方と見なされる場合の動作に関心がありますが、Cでは、これは警告のみを生成し、エラーは生成しません。

私がハーブサッターや他の人たちから読んだことからvolatile、少なくともC / C ++に関する限り、並行プログラミングは完全に直交する概念であると思うでしょう。

ただし、GCC実装では、のすべてstd::atomicのメンバー関数にvolatile修飾子があります。同じことがAnthonyWilliamsのの実装にも当てはまりますstd::atomic。

では、どうしたのか、私のatomic<>変数は必要volatileかどうか？

最近投稿したこの回答に示されているようにvolatile、マルチスレッド プログラミング コンテキストでのユーティリティ (またはその欠如) について混乱しているようです。

私の理解は次のとおりです。変数にアクセスするコードの制御フローの外部で変数が変更される可能性がある場合はいつでも、その変数は であると宣言する必要がありますvolatile。シグナル ハンドラ、I/O レジスタ、および別のスレッドによって変更された変数はすべて、このような状況を構成します。

したがって、グローバルな intfooがあり、fooあるスレッドによって読み取られ、別のスレッドによって (おそらく適切なマシン命令を使用して) アトミックに設定される場合、読み取りスレッドは、シグナル ハンドラーによって微調整された変数を見るのと同じ方法でこの状況を認識します。外部ハードウェア条件によって変更されるため、foo宣言する必要がありますvolatile(または、マルチスレッドの状況では、おそらくより良い解決策であるメモリ フェンシング ロードでアクセスします)。

どのように、どこで間違っていますか?

以前のいくつかの質問/回答で明確にされていますが、これはvolatileマルチスレッドではなく、C++ メモリ モデルの可視状態に関連しています。

一方、Alexandrescu によるこの記事volatileでは、このキーワードをランタイム機能としてではなく、コンパイル時のチェックとして使用して、コンパイラがスレッド セーフではない可能性のあるコードを受け入れないように強制しています。この記事では、キーワードはrequired_thread_safety、実際に意図されているvolatile.

volatileこれは適切なの（乱用）使用ですか？このアプローチには、どのような落とし穴が隠されている可能性がありますか?

最初に頭に浮かぶのは、追加の混乱です。volatileこれはスレッド セーフとは関係ありませんが、より優れたツールがないため、それを受け入れることができました。

記事の基本的な簡略化:

variable を宣言すると、その変数volatileに対してメンバー メソッドのみvolatileを呼び出すことができるため、コンパイラは他のメソッドへのコードの呼び出しをブロックします。std::vectorインスタンスを as として宣言するvolatileと、クラスのすべての使用がブロックされます。const_cast要件を解放するために実行するロッキング ポインターの形でラッパーを追加すると、ロッキング ポインターをvolatile介したすべてのアクセスが許可されます。

記事からの盗用:

ノート

最初のいくつかの回答が表示された後、最も適切な言葉を使用していない可能性があるため、明確にする必要があると思います。

の使用は、volatileそれが実行時に提供するもののためではなく、コンパイル時にそれが何を意味するかによるものです。つまり、constキーワードがユーザー定義型でほとんど使用されていない場合、同じトリックをキーワードで引き出すことができますvolatile。つまり、メンバー関数呼び出しをブロックできるキーワード (たまたま volatile と綴られている) があり、Alexandrescu はそれを使用して、コンパイラをだましてスレッドセーフでないコードのコンパイルに失敗させています。

コンパイル時に何をするかという理由ではなく、コンパイラに何をさせるかという理由でそこにある多くのメタプログラミングのトリックと私は考えています。

volatile 型へのポインターを cout しようとすると、通常は cout が文字列を出力すると予想される volatile char ポインターであっても、代わりに単に '1' を取得します (ポインターが null でないと仮定します)。出力ストリーム operator<< は揮発性ポインターに特化したテンプレートだと思いますが、私の質問はなぜですか? この動作の動機となるユースケースは何ですか?

コード例:

出力：

この質問は主に学術的なものです。これが私にとって実際の問題を引き起こすからではなく、好奇心からお願いします。

次の誤ったCプログラムについて考えてみます。

ハンドラーがプログラムフローを中断するため、このプログラムは正しくrunningありません。したがって、いつでも変更できるため、宣言する必要がありますvolatile。しかし、プログラマーがそれを忘れたとしましょう。

gcc 4.3.3は、-O3フラグを使用して、ループ本体を（フラグを最初にチェックした後running）無限ループにコンパイルします。

これは予想されていた。

while次に、ループ内に次のような些細なことを入れます。

そして突然、gccはループ条件を最適化しなくなりました！ループ本体のアセンブリは次のようになります（ここでも-O3）：

runningループを通過するたびにメモリから再ロードされることがわかります。レジスターにもキャッシュされません。どうやらgccは、の値runningが変更された可能性があると考えているようです。

では、なぜgccはrunning、この場合の値を再チェックする必要があると突然判断するのでしょうか。