c++ - std：mapおよびstd：setのスレッドセーフ

Question

重複の可能性：
マルチスレッド環境でSTLコンテナーへの読み取りアクセスを保護する必要がありますか？

別のスレッドがこのセットまたはマップに書き込んでいるときに、あるスレッドが：setまたは：mapを読み取った場合、どうなりますか？例外？

現在、読み取り/書き込みロックを使用していますが、書き込み操作は頻繁ではなく、読み取り操作は非常に頻繁であるため、ロックを削除したいと思います。

Answer 1

競合状態が発生します。CPUの実行順序に応じて、毎回異なる結果が得られます。イテレータが無効にされ（たとえば、一方のスレッドでアイテムを削除し、もう一方のスレッドに、現在無効なメモリを指すイテレータがある場合）、もう一方のスレッドで使用されると、未定義の動作が発生するため、死んだ赤ちゃん、粘土に注意してくださいゴーレム、ホーント、およびより可能性の高いsegfault、遅延segfault、およびランタイムクラッシュ。

C ++ 11ではmutex、その他のスレッド機能が導入されています。必要に応じて、読み取りと書き込みをそれらで保護してください。

Answer 2

mutexs、locks....brrrはフリーロックコンテナを使用しようとします。たとえば、Intelの「スレッディングビルディングブロック」、別名TBB http://threadingbuildingblocks.org/files/documentation/a00130.html

Answer 3

標準のコンテナはスレッドセーフではなく、Javaの意味で「フェイルファスト」イテレータを持つように指定されていません。したがって、保護されていない同時アクセスで問題が発生する可能性のあるものが少なくとも2つあります。

1. コンテナでのデータ競合。これは未定義の動作です。
2. 1つのスレッドがイテレータを無効にし、後で別のスレッドが同じ値のイテレータを使用します。これも未定義の動作ですが、必ずしもデータの競合ではなく、シングルスレッドプログラムのバグでもあります。異なるスレッドで使用されている場合、同じコンテナー上の複数のイテレーターを見失うのは少し簡単です。

C ++の哲学は「速く成功する」ことであり、プログラマーが失敗したときに何が起こるかを気にしないことだと言う人もいるかもしれません;-)。したがって、多くのユーザーにとって冗長になる組み込みのロックはありません。set代わりに、それはあなたの問題です-セットが同時にアクセスされていない場合でも、ロックがこのプログラムとあなたがこれまでに書いた他のすべてのプログラムを遅くしていることに不満を抱くよりも、ロックがこのプログラムを遅くしていることに不満を感じるでしょう。

書き込み操作は頻繁ではなく、読み取り操作は非常に頻繁です。

それはまさにリーダーライターロックがうまく機能するはずの状況です。状況を改善できる唯一の方法は、書き込み操作を「頻繁ではない」から「まったくない」に減らすことができる場合です。これはおそらく不可能です。