問題タブ [double-checked-locking]

C# では、次のコード (このページから) を使用して、スレッド セーフな方法でシングルトン クラスを遅延インスタンス化できます。

同等のスレッドセーフな Delphi コードは何ですか?

この記事では、Java の Double Checked Locking に関する 2 つの問題についても言及しています。

• ヘルパー参照が新しく作成されたオブジェクトを指すように作成される前に、新しいオブジェクトが構築される可能性があります。つまり、2 つのオブジェクトが作成されます。
• オブジェクトがまだ作成されている間に、ヘルパー参照がメモリのブロックを指すように作成される可能性があります。つまり、不完全なオブジェクトへの参照が返されます。

そのため、前述の記事の C# と Java バージョンのコードはほとんど同じように見えますが、C# バージョンだけが期待どおりに機能します。これら 2 つの問題が Delphi バージョンの Double-Checked Locking にも存在する場合、追加の質問につながるのはどれですか?

私はPHPが初めてなので、始めるためにシングルトンを実装することにしました。

PHP でシングルトン パターンを再現することはできますが、ダブルチェック ロックを実装する方法がわかりません。

それはPHPでも可能/必要ですか。PHP がマルチスレッド化されていないことをどこかで読んだことがありますか? 誰かがそれを確認できますか？

マルチスレッドの場合、PHP で lock() または synchronize() がどのように機能するかを誰かに説明してもらえますか?

ありがとう、ヘンリー

Meyer、Phoenix など、C++ でのシングルトン実装アプローチについて多くのことを聞いたり読んだりしましたが、それらはすべて特定の使用シナリオで問題があるように見えました。そこで私は、独自の実装アプローチであるDaniel Singletonを思いつきました。私が知りたいのは、それが正しいかどうかです... 正しいと思いますが、思いもよらなかった欠陥があれば教えてください!

また、ダブルチェックロックを使用して、常にロックを取得することなくスレッドセーフにしようとしましたが、これについてもよく読んだのですが、誰もが壊れていると述べました。私もそれを修正しようとしましたが、私の解決策が正しいかどうかを知りたいです...そうでない場合、どうして失敗するのでしょうか?

重複の可能性：
.netでのロックの再確認

編集：この質問を明確にするための多くの編集はシングルトンに関するものではありません

私は自分がこのようなコードを書いていることに気づきました：

UpdateResource()遅い操作です。このパターンは意味がありますか？
より良い選択肢はありますか？

C++ と二重チェック ロックの危険性には、著者が提案するパターンを正しく実装するための persudo コードがあります。下記参照、

最初のメモリバリアを return ステートメントのすぐ上に移動できるかどうか疑問に思っていますか?

編集：別の質問：リンクされた記事で、vidstigeが引用したように

技術的には、完全な双方向バリアは必要ありません。最初のバリアは、(別のスレッドによる) Singleton の構造の下方への移行を防止する必要があります。2 番目のバリアは、pInstance の初期化の上方移行を防止する必要があります。これらは「取得」および「解放」操作と呼ばれ、区別を行うハードウェア (Itainum など) 上の完全なバリアよりも優れたパフォーマンスをもたらす可能性があります。

2 番目のバリアは双方向である必要はないと言われていますが、pInstance への割り当てがそのバリ​​アの前に移動されないようにするにはどうすればよいでしょうか? 最初のバリアは上向きの移行を防ぐことができますが、別のスレッドはまだ初期化されていないメンバーを見る機会があります。

編集：最初の障壁の目的をほぼ理解していると思います。sonicoderが指摘したように、if が true を返すと、分岐予測により tmp が NULL になる可能性があります。この問題を回避するには、if を読み取る前に tmp を読み取らないようにするための取得バリアが必要です。

最初のバリアは 2 番目のバリアとペアになって同期関係を実現するため、下に移動できます。

編集:この質問に興味がある人は、memory-barriers.txtを読むことを強くお勧めします。

次のように、べき等で常に同じ値を返し、チェック例外をスローする可能性のある引数のない静的メソッドがあるとします。

返されたオブジェクトを構築するものが高価で決して変更されない場合、これは遅延シングルトンの良い候補です。1 つの選択肢は、Holder パターンです。

残念ながら、(暗黙の) 静的初期化ブロックからはチェック済み例外をスローできないため、これはうまくいきません。コールbar()):

この時点で、ロックを再確認したほうがすっきりするのではないでしょうか?

DCL はまだアンチパターンですか? ここで見逃している他の解決策はありますか (際どいシングル チェックのようなマイナー バリアントも可能ですが、解決策を根本的に変更しないでください)。どちらかを選択する正当な理由はありますか?

上記の例は試していないので、コンパイルできない可能性は十分にあります。

編集: このシングルトンの消費者 (つまり、の呼び出し元) を再実装または再構築する余裕はありFoo.bar()ません。また、この問題を解決するために DI フレームワークを導入する機会もありません。私は主に、特定の制約内で問題を解決する回答 (呼び出し元に伝達されるチェック済み例外を含むシングルトンの提供) に興味があります。

更新:結局、DCL を使用することにしました。これは、既存のコントラクトを保持する最もクリーンな方法を提供し、適切に行われた DCL を避けるべき具体的な理由を誰も提供しなかったためです。同じことを達成するための非常に複雑な方法であるように思われたため、受け入れられた回答ではこの方法を使用しませんでした。

人々がリソースを要求するWebアプリケーションがあります。このリソースは、効率化のために同期ハッシュマップを使用してキャッシュされます。ここでの問題は、2つの異なるリクエストが同じキャッシュされていないリソースに対して同時に発生する場合です。リソースを取得する操作は大量のメモリを消費するため、同じリソースに対して複数回呼び出すことは避けたいと思います。

次のスニペットに潜在的な問題があるかどうか誰かに教えてもらえますか？前もって感謝します。

多くの人によると、1.5 以降を実行していてvolatileキーワードを使用しない限り、やや一般的な Double-Checked Locking イディオムは Java では壊れています。

壊れたダブルチェック ロックのサンプル:

サンプルはこの記事からのもので、修正方法の詳細も記載されています: http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html

上記の Pugh の分析は、Java VM に関するものです。私は Android で作業しており、Double-Checked Locking を使用するライブラリを頻繁に使用しています。dalvik VM のメモリ モデルはこのイディオムをサポートしていますか?

このコードは、Java の二重チェック ロックの問題を解決しますか?

注意すべき点が 2 つあります。

1. getInstance()は同期されないため、INSTANCE が初期化された後、同期のコストはかかりません
2. createInstance()同期されています

問題は、このコードに何か問題があるかどうかです。それは合法で、常にスレッドセーフですか?

C ++ 11の新しいマシンモデルにより、マルチプロセッサシステムが確実に機能するようになります。指示の再編成に。

MeyersとAlexandrescuが指摘したように、「単純な」ダブルチェックロックパターンの実装はC++03では安全ではありません。

彼らは彼らの記事で、プログラマーとして何をしても、C ++ 03ではコンパイラーの自由度が高すぎることを示しました。つまり、1つだけになるかどうか確信が持てない方法で命令を並べ替えることができます。のインスタンスSingleton。

私の質問は今です：

• 新しいC++11マシンモデルの制限/定義により、命令のシーケンスが制約され、上記のコードは常にC ++ 11コンパイラで機能しますか？
• 安全なC++11-このシングルトンパターンの実装は、（ここのモックの代わりに）新しいライブラリ機能を使用するとどのようになりLockますか？