問題タブ [concurrent-collections]

C＃のコレクションの背後にあるスレッドセーフ理論の概要を把握しようとしています。

Javaのように同時コレクションがないのはなぜですか？（java docs）。一部のコレクションはスレッドセーフのように見えますが、たとえば次の点に関して、どのような位置にあるのかは私にはわかりません。

• 複合操作、
• イテレータの使用の安全性、
• 書き込み操作

車輪の再発明はしたくない！（私はマルチスレッドの第一人者ではなく、とにかくこれがどれほど難しいかを過小評価していません）。

コミュニティがお役に立てば幸いです。

弱いキーまたは/および弱い値を持つマップを提供する C# クラスはありますか? または、少なくとも WeakHashMap のような機能。

私の問題

ロングポーリングアプリケーションのために、ある種のデータ構造でメッセージを保持したいとします。

index [4,5]からのメッセージを要求すると、次のように返されます "my","car"。

次に、しばらくすると、古いメッセージは役に立たなくなったため、メモリを節約したいので、それらを削除したいとします。x時間の経過後にメッセージ[1-3]が古くなったとしましょう。x1秒に1回だけ削除するのが最も効率的だと思います。次に、私のデータ構造には次のものが含まれている必要があります。

私の解決策は？

concurrentskiplistsetまたはconcurrentskiplistマップを使用することを考えていました。また、の中から古いメッセージを削除することを考えていましたnewSingleThreadScheduledExecutor。これを（効率的に/スレッドセーフに）実装する方法、またはライブラリを使用する方法を知りたいですか？

次のように定義されたグリッドがありますList<List<Cell>>。「セル」は私のカスタムクラスです。私のプログラムには、グリッド上のさまざまな座標にアクセスし、「Cell」クラスのデータを変更するスレッドがいくつかあります。しかし、一度に「Cell」オブジェクトにデータを書き込むスレッドは 1 つだけです。ConcurrentBag などの並行コレクションを使用すると役立つと思いましたが、すべての並行コレクションにはアイテムを追加するか、コレクションからアイテムを削除するメソッドしかないようです。そのようなコレクション内に保持されているデータを変更するためのスレッドセーフな方法はないようです。

ここで何か不足していますか、またはそのようなコレクションを使用してそれを行う「簡単な方法」はありませんか?

タイトルごとに-IListまたはIDictionaryでのフェイルセーフ反復のためのC＃/。NETの優れた組み込みオプションはありますか？

私が問題にぶつかっているのは、次のようなコードです。

これは、foo.Barが最初にtrueになった後に次をスローします。

簡単な回避策は実行することですforeach (Foo foo in new List<Foo>(someList))が、それを毎回実行することを覚えておく必要があるのは面倒です。独身。時間。これが出てきます。

Javaのバックグラウンドから来ているので、CopyOnWriteArrayList / ConcurrentHashMapで適切に処理できます（これらのリストの使用に関連する他のペナルティがあることを認識しています）。C＃に、私が気付いていない同等のものはありますか？

私は StackOverflow を検索しましたが、多くの ConcurrentModificationException の質問があります。それらを読んだ後、私はまだ混乱しています。私はこれらの例外をたくさん受けています。オブジェクトを追跡するために「レジストリ」セットアップを使用しています。

次のように ArrayLists にアクセスして、これらのリストにオブジェクトを追加および削除していますRegistry.effects.add(obj)。Registry.effects.remove(obj)

再試行ループを使用して、いくつかのエラーを回避することができました。

しかし、それ以外の場合、これは実用的ではありません。drawProjectiles()何も変更していないにもかかわらず、メソッドで ConcurrentModificationExceptions を取得し続けます。犯人は、画面に触れた場合だと思います。これにより、新しい Projectile オブジェクトが作成され、 draw メソッドがまだ反復している間に Registry.proj に追加されます。

draw メソッドで再試行ループをうまく実行できないか、オブジェクトの一部を再描画します。だから今、私は新しい解決策を見つけることを余儀なくされています..私がやっていることを達成するためのより安定した方法はありますか?

ああ、私の質問のパート 2: 多くの人が (私が使用してきたように) ListIterators を使用することを提案していますが、私は理解できませんListIterator.remove()。イテレータ自体？

キューを操作する最良の方法は何かを理解しようとしています。DataTable を返すプロセスがあります。次に、各 DataTable が前の DataTable とマージされます。1 つの問題があります。最後の BulkCopy (OutOfMemory) まで保持するにはレコードが多すぎます。

したがって、受信する各 DataTable をすぐに処理する必要があると判断しました。ConcurrentQueue<T>...について考えてみますが、WriteQueuedData()メソッドがテーブルをデキューしてデータベースに書き込む方法を知る方法がわかりません。

例えば：

私の最初の質問は、サブスクライブするイベントが実際にないという事実を除けば、ExtractData()非同期で呼び出す場合、これだけで十分でしょうか? 第二に、機能の仕方について何か欠けていConcurrentQueue<T>て、キューに入れられたオブジェクトと非同期に動作するために何らかの形のトリガーが必要ですか?

更新ConcurrentQueue<T>OnItemQueued イベント ハンドラーを持つ クラスを派生させました。それで：

この実装に関する懸念事項はありますか?

ConcurrentDictionary の AddOrUpdate メソッドを基本的に使用して、同時コレクションとスレッド化で問題に直面しています.....私はそれを使用することができません..良い例を見つけることができませんでした...また、できませんでしたMSDN プログラミング ガイドの ConcurrentQueue の例を完全には理解していません。

基本的に ConcurrentDictionary の AddOrUpdate メソッド.....私はそれを使用することができません..良い例を見つけることができませんでした...そして完全に理解できませんでした.MSDNプログラミングガイドのConcurrentQueueの例..

並行コレクションが名前空間であり、クラスであることを除けば、名前空間SynchronizedCollection<T>内の並行コレクションはどのようにSystem.Collections.Concurrent異なりますか?SynchronizedCollection<T>

SynchronizedCollection<T>また、Concurrent Collections のすべてのクラスは、スレッド セーフなコレクションを提供します。どちらをいつ使用するかを決定するにはどうすればよいですか? また、その理由は?

プロジェクトを開始する前に、(System.Collections.Concurrent) からの ConcurrentBag のパフォーマンスをロックとリストと比較する簡単なテストを作成しました。ConcurrentBag が単純な List でロックするよりも 10 倍以上遅いことに非常に驚いています。私が理解していることから、ConcurrentBag は、リーダーとライターが同じスレッドである場合に最適に機能します。しかし、従来のロックよりもパフォーマンスが大幅に低下するとは思いませんでした。

リスト/バッグへの書き込みと読み取りを行う 2 つの Parallel for ループでテストを実行しました。ただし、書き込み自体には大きな違いがあります。

私のボックスでは、このコードの 0.5 ～ 0.9 秒と比較して、実行に 3 ～ 4 秒かかります。

前述したように、読み取りと書き込みを同時に行っても、同時バッグ テストには役立ちません。私は何か間違ったことをしていますか、それともこのデータ構造は本当に遅いですか?

[編集] - ここでは必要ないため、タスクを削除しました (完全なコードには別のタスクの読み取りがありました)

[編集] 回答ありがとうございます。いくつかの答えが混在しているように見えるので、「正しい答え」を選ぶのに苦労しています。

Michael Goldshteyn が指摘したように、速度は実際にはデータに依存します。Darin は、ConcurrentBag を高速化するにはもっと多くの競合が必要であり、Parallel.For は必ずしも同じ数のスレッドを開始するとは限らないと指摘しました。覚えておくべき 1 つのポイントは、ロック内で必要のないことは何もしないことです。上記の場合、一時変数に値を代入している可能性を除いて、ロック内で何もしていないように見えます。

さらに、sixlettervariables は、たまたま実行されているスレッドの数も結果に影響を与える可能性があることを指摘しましたが、元のテストを逆の順序で実行してみましたが、ConcurrentBag は依然として低速でした。

15 個のタスクを開始していくつかのテストを実行しましたが、結果は特にコレクションのサイズに依存していました。ただし、ConcurrentBag は、最大 100 万回の挿入で、リストをロックするのとほぼ同じかそれ以上のパフォーマンスを発揮しました。100 万を超えると、ロックがはるかに高速になることがあるように見えましたが、私のプロジェクトでこれより大きなデータ構造を使用することはおそらくないでしょう。実行したコードは次のとおりです。