問題タブ [double-checked-locking]

私は「ダブルチェックロック」に関するこの記事を読んでいて、記事のメイントピックから離れて、なぜ記事のある時点で著者が次のイディオムを使用するのか疑問に思っていました:

リスト 7. 順不同の書き込み問題の解決を試みる

そして私の質問は、同じロックでコードを 2 回同期する理由はありますか? これは何か目的がありますか？

よろしくお願いします。

「インスタンスフィールドの遅延初期化のためのダブルチェックイディオム」を検討してください。

/blockquote>

フィールドを安全な方法でリセットできるようにしたい (私の場合は、データベースから強制的に再度ロードする)。reset メソッドを使用することでこれを行うことができると思います。

/blockquote>

これは、フィールドをリセットする標準的な方法ですか? 安全ですか？落とし穴はありますか？ブロッホがダブルチェック遅延読み込みについて次の警告を出したので、私が尋ねているのです。良い考えではありませんが、ここでは適切です。」

ヒマラヤのプラヤさん、よろしくお願いします。

Checkstyle reports this code as "The double-checked locking idiom is broken", but I don't think that my code actually is affected by the problems with double-checked locking.

The code is supposed to create a row in a database if a row with that id doesn't exist. It runs in a multi-threaded environment and I want to avoid the primary-key-exists SQL-exceptions.

The pseudo-code:

I can agree that it looks like double-checked locking, but I am not using static variables and the code in fetch() and create() is probably too complex to be inlined and put out of order.

Am I wrong or checkstyle? :)

Java でダブルチェック ロック パラダイムが壊れている理由を説明しているこの記事に出くわしました。変数が宣言されている場合、パラダイムは .NET (特に C#) で有効ですvolatileか?

そのため、複数のスレッドが遅延して作成されたシングルトンを初期化しようとするのを防ぐために一般的に使用される C++ の二重チェック ロックが壊れていると主張する多くの記事を見てきました。通常の二重チェック ロック コードは次のようになります。

問題は明らかにインスタンスを割り当てる行です-コンパイラは自由にオブジェクトを割り当ててからそれにポインタを割り当てるか、またはポインタを割り当てられる場所に設定してから割り当てます。後者のケースはイディオムを壊します -- 1 つのスレッドはメモリを割り当ててポインタを割り当てますが、スリープ状態になる前にシングルトンのコンストラクタを実行しません -- 次に、2 番目のスレッドはインスタンスが null ではないことを確認し、それを返そうとします、まだ構築されていませんが。

の代わりにスレッドローカルブール値を使用してチェックするという提案を見ましたinstance。このようなもの：

このようにして、各スレッドはインスタンスが一度作成されたかどうかをチェックしますが、その後停止します。これにより、パフォーマンスが低下しますが、すべての呼び出しをロックするほど悪くはありません。しかし、ローカルな静的 bool を使用した場合はどうなるでしょうか?:

なぜこれがうまくいかないのですか？sync_check が別のスレッドで割り当てられているときに 1 つのスレッドによって読み取られたとしても、ガベージ値はゼロ以外であり、したがって true になります。この Dr. Dobb の記事では、命令の並べ替えをめぐってコンパイラとの戦いに勝つことはできないため、ロックする必要があると主張しています。これは何らかの理由で機能しないはずだと思いますが、その理由はわかりません。Dr. Dobb の記事にあるように、シーケンス ポイントの要件が失われているとすれば、ロックの後のコードをロックの前に並べ替えることができない理由がわかりません。これにより、C++ マルチスレッドが壊れた期間になります。

ローカル変数であるため、コンパイラが sync_check をロックの前に特別に並べ替えることが許可されていることがわかると思います（静的であっても、参照やポインターを返していません）-しかし、これはまだ解決できます代わりに静的メンバー (事実上グローバル) にすることによって。

それで、これは機能しますか、それとも機能しませんか？なんで？

最近、Java の二重チェック ロック パターンとその落とし穴について説明している記事を偶然目にしました。今、私が何年も使用しているそのパターンの変形が問題の影響を受けやすいかどうか疑問に思っています。

この件に関する多くの投稿や記事を見て、部分的に構築されたオブジェクトへの参照を取得する際の潜在的な問題を理解しました。私が知る限り、私の実装はこれらの問題の影響を受けるとは思いません. 次のパターンに問題はありますか?

もしそうでなければ、なぜ人々はそれを使わないのでしょうか? この問題に関して私が見たどの議論でも、それが推奨されているのを見たことがありません。

二重チェックのロック修正が機能しない方法についてはすべて読んだことがあり、遅延初期化は好きではありません。

これが私の例です: private int timesSafelyGotten = 0; プライベート ヘルパー ヘルパー = null;

このように、同期コードはヘルパーを作成するために 1 回実行し、最初に取得するときに 1 回実行する必要があるため、理論的には、ヘルパーを作成した同期コードがロックを解放し、ヘルパーの初期化が完了するまで、 timesSafelyGotten をインクリメントすることはできません。

問題はないと思いますが、あまりにも単純すぎて、本当であるとは思えません。どう思いますか?

カレブ・ジェームズ・デリスル

そのため、現時点では、ダブルチェック ロックをそのまま使用しても C++ では機能しないことがわかっています。少なくとも、移植性のある方法では機能しません。

テレイン レイ トレーサーに使用する遅延四分木に脆弱な実装があることに気付きました。そこで、メモリ使用量を 4 倍にしたり、実装されたアルゴリズムの大部分を並べ替えたりしたくないので、安全な方法で遅延初期化を引き続き使用する方法を見つけようとしました。

このトラバーサルは、 C++の 12 ページのパターンと二重チェックのロックの危険性に触発されていますが、より安価に実行しようとしています。

#pragma flushまた、コンパイラとプロセッサがそれらの間で操作の順序を変更することが許可されないハードシーケンスポイントとしても機能すると想定されています。

どのような問題が見られますか?

編集:バージョン 2、Vlads の回答を考慮しようとしています (3 番目のフラッシュを導入):

編集:バージョン 3、これはバージョン 2 とかなり同等であることがわかりました。これは、子自体を使用しているのではなく、有効性をチェックするためにプリミティブ フラグを使用しているためです。基本的には、子の作成とそのフラグへの書き込みの間のメモリ バリアに依存しています。

私はマイク・アッシュの「シングルトンのケアと給餌」でこれに出くわし、彼のコメントに少し戸惑いました:

ただし、このコードは少し遅いです。ロックを取得するには、多少のコストがかかります。それをより苦痛にしているのは、ほとんどの場合、ロックが無意味であるという事実です。ロックが必要になるのは、foo が nil の場合だけです。これは、基本的に 1 回だけ発生します。シングルトンが初期化されると、ロックは必要なくなりますが、ロック自体は残ります。

私の質問は、これには間違いなく正当な理由がありますが、foo が nil のときにロックを制限するように記述できないのはなぜですか (以下を参照)。

乾杯ゲイリー