list :: empty（）マルチスレッドの動作？

さまざまなスレッドが要素を取得するためのリストがあります。リストが空のときに保護しているmutexをロックしないようにするために、ロックするempty()前にチェックします。

呼び出しがlist::empty()100％正しくない場合でも問題ありません。同時list::push()およびlist::pop()コールのクラッシュまたは中断を回避したいだけです。

私はVC ++とGnu GCCが時々empty()間違って、何も悪いことはないと思い込んでも大丈夫ですか？

if(list.empty() == false){ // unprotected by mutex, okay if incorrect sometimes
    mutex.lock();
    if(list.empty() == false){ // check again while locked to be certain
         element = list.back();
         list.pop_back();
    }
    mutex.unlock();
}

呼び出しがlist::empty()100％正しくない場合でも問題ありません。

いいえ、大丈夫ではありません。同期メカニズム（ミューテックスのロック）の外でリストが空かどうかを確認すると、データ競合が発生します。データの競合があると、未定義の動作が発生します。未定義の動作があるということは、プログラムについてもはや推論できず、得られる出力はすべて「正しい」ことを意味します。

健全性を重視する場合は、パフォーマンスヒットを取得し、チェックする前にミューテックスをロックします。そうは言っても、リストはあなたにとって正しいコンテナではないかもしれません。あなたがそれを使って何をしているのかを正確に知らせることができれば、より良いコンテナを提案できるかもしれません。

互いに同期していない読み取りと書き込み（おそらく、そのような名前が付けられていると仮定すると、のsizeメンバーへの書き込みstd::list）があります。一方のスレッドが（外部で）呼び出し、もう一方のスレッドが内部に入り、実行されると想像してください。次に、変更されている可能性のある変数を読み取っています。これは未定義の動作です。empty()if()if()pop_back()

物事がうまくいかない例：

十分にスマートなコンパイラはmutex.lock()、list.empty()戻り値を変更できない可能性があるため、内部ifチェックを完全にスキップし、最終的pop_backに、最初のの後に最後の要素が削除されたリストのにつながる可能性がありますif。

なぜそれができるのですか？では同期は行われないlist.empty()ため、同時に変更された場合、データ競合が発生します。標準では、プログラムにはデータ競合がないものとするため、コンパイラーはそれを当然のことと見なします（それ以外の場合、最適化はほとんど行われません）。したがって、非同期のシングルスレッドの視点を想定して、list.empty()一定に保つ必要があると結論付けることができます。

これは、コードを破壊する可能性のあるいくつかの最適化（またはハードウェアの動作）の1つにすぎません。