コードで同時実行の問題を解決しようとしたときに、この問題に遭遇しました。元のコードでは、一意のロックのみを使用して、stl マップであるキャッシュへの書き込み操作をロックしています。ただし、キャッシュへの読み取り操作に制限はありません。そのため、読み取り操作に共有ロックを追加し、書き込み操作に一意のロックを保持することを考えていました。しかし、誰かが私に、マップ自体が行う内部キャッシュの問題があるため、マップでマルチスレッドを実行するのは安全ではないと言っていました。
誰かが理由を詳しく説明できますか？内部キャッシュは何をしますか?
キャッシュの問題が発生する理由が本当にわかりません...
マップの stl 定義を参照する場合は、二分探索木として実装する必要があります。
二分探索木は、キーと値のノードのプールを持つ単純な木です。これらのノードはキーの自然な順序に従ってソートされ、問題を回避するためにキーは一意である必要があります。したがって、内部キャッシュはまったく必要ありません。
内部キャッシュが不要なため、読み取り操作はマルチスレッド コンテキストで安全です。ただし、書き込み操作の場合は同じ話ではありません。スレッドを認識しないデータ構造の場合と同様に、独自の同期メカニズムを提供する必要がある場合です。
書き込み操作がスレッドによって実行されるときは、読み取り操作も禁止する必要があることに注意してください。この書き込み操作は、バイナリ ツリーのゆっくりとした完全な再調整をもたらす可能性があるためです。つまり、長い書き込み操作中にすばやく読み取り操作を行うと、間違った結果。
少なくとも C++11 以降、標準ライブラリ クラスに対する操作はスレッド セーフであることが保証されています (その中に格納されているオブジェクトに対する操作はスレッド セーフであるとconst仮定します)。const
型のすべてのconstメンバー関数は、std明示的な同期を行わなくても、C++11 の複数のスレッドから安全に呼び出すことができます。実際、標準ライブラリと組み合わせて使用される型 (たとえば、コンテナーへのテンプレート パラメーターとして) は、この保証を満たさなければなりません。
明確化: 標準では、間に同期ポイントがなければ、同じデータ位置への書き込みやその他のアクセスが発生しない限り、プログラムが目的の動作をすることが保証されています。この背後にある理論的根拠は、最新の CPU には、スケーラビリティとパフォーマンスを制限する厳密な順次一貫性のあるメモリ モデルがないためです。内部では、コンパイラと標準ライブラリは、より強力なメモリ順序付けが必要な場所で適切なメモリ フェンスを発行します。