11
私はN要素のベクトルを持っていますが、このベクトルのn要素まで意味のあるデータを持っています。 1つのアップデータスレッドは、n番目またはn + 1番目の要素を更新し（n = n + 1に設定）、nがNに近すぎるかどうかをチェックし、必要に応じてvector :: resize（N + M）を呼び出します。更新後、スレッドは複数の子スレッドを呼び出してn番目のデータを読み込み、いくつかの計算を行います。STLベクトルとスレッドセーフ
子スレッドは決してデータを変更または削除しないことが保証されています（実際にデータが削除されることはありません）。アップデータは更新の終了直後に子を呼び出します。
これまでのところ問題は発生しませんでしたが、以前の更新から子作業スレッドが残っている場合は、大きなメモリブロックにベクトルを再割り当てする際に問題が発生するかどうか尋ねたいと思います。
このようなマルチスレッドの場合、スレッドセーフではないため、ベクターを使用するのは安全ですか？
EDIT： アップデーターがvector :: resize（N + M、0）を呼び出すときに挿入が行われるだけなので、私の問題の解決策はありますか？ STLベクトルの優れた性能のために、私はそれをロック可能なベクトルに置き換えるつもりはないか、この場合、実行可能な、既知のロックフリーなベクトルはありますか？
@James McNellis：はい。それは良いアドバイスです。私は自分自身を再配分することができます。実際には、ベクトルへのポインタを保持するクラス内でベクトルがラップされます。それはshared_ptrではありませんが、私は簡単に新しい大きなベクトルを構築し、古いものから要素をコピーして削除します。だから、大きなメモリブロックをコピーする最速の方法は何ですか。 CopyMemory（）？ –
ベクトルの代わりに 'std :: deque'を使うほうが簡単な解決法ではないでしょうか？これにより、再配分は完全に回避されますが、ベクトルとほぼ同等のパフォーマンスが得られます。 – jalf
@ jalf：再割り当てだけが問題ではないので、 'std :: deque'を使うのは安全だとは思いません。 'std :: deque :: operator []'がサイズやdequeの内部の他の簿記をチェックしないという保証はないので、消費者が 'operator []を呼び出す競合状態の可能性があります'は、プロデューサがデータを追加している間に内部状態を読み取り、内部状態を変更します。 –