私は、フォームのコレクションを持っている：これらの条件でSTLでのスレッディングには問題ありませんか？
map<key, list<object> >
私は今まで、リストの後ろに挿入し、時々私は、マップ全体から読み取る（私は初期化時を除き、マップに書き込むことはありません）。
私が理解しているように、STLコンテナのどれもスレッドセーフではありませんが、実際にはキーあたり最大1つのスレッドしか持つことができません。私はこの取り決めでかなり安全であると仮定して何かを見失っていますか？
マルチスレッドのシナリオでマップが変更されない場合は、問題ありません。それぞれのスレッドが独自のリストを参照すると、それはスレッドプライベートデータなので、うまくいきます。
キーが[マップ]にまだ存在しない場合は挿入（変更）するため、キーを[キー]で検索しないように注意してください。
しかし、なぜこの構造が必要なのか不思議です。なぜならポインタ/参照または実際のリストオブジェクト自体を各スレッドのスタック上に保持しておくのはなぜですか？
（そうでない場合は、リスト上の適切な同期を必要とする。）実際に
あなたは「全体マップから」と言う - おそらく任意のランダムなスレッドのいずれかを反復処理しようとするかもしれないことを意味リスト。したがって、リストの操作を確実に同期させる必要があります。
TBH任意の書き込みと読み取りの周りにクリティカルセクションを置く限り、正常に動作します。
+1私は同意します。 1つのスレッドだけがキーにアクセスしたり、シンクロを使用するという事実を裏付ける明示的な構造を持つ方がよいでしょう。問題をこのようにしておくと、誰かがあなたのコードを（遅くても）あなたのコードを使用していて遅かれ早かれ使用し、ひどいバグにつながる「1つのキー1つのスレッドの必要条件」を忘れることになります... – neuro
私は分かりません。それは貧しい人のキャッシュのようなものです。 実際の問題は、ここで私たちのデータベースを混乱させ、アクセスフロントエンドを使用して重要なデータにテーブルロックを引き起こしてしまうことです（はい、わかります）。残念なことに彼は大統領と良い友人なので、誰も解雇されずにこれらの問題を引き起こさないように誰にでも知らせることができないので、私は問題に疲れて、誰も触れられない別のマシンのメモリに従業員によるデータの一部をキャッシュしたかったこの馬鹿の定数ロックのためにデータベースが使用不能になった場合、データベースを更新するためにキューに保持されます。 –
ああ、「地図全体を読む」は、ウォッチャースレッドによって行われ、汚れた挿入物や更新を見つけてデータベースに書き戻します。その部分もシングルスレッドなので、私が見ることができる唯一の問題はスキャン中の挿入です。多分それは同期化が必要な場所です...うーん。 –