スレッド間で共有変数を変更するコードが競合状態の影響を受けないのはなぜですか？

私はCygwin GCCを使用しており、次のコードを実行します。

#include <iostream>
#include <thread>
#include <vector>
using namespace std;

unsigned u = 0;

void foo()
{
    u++;
}

int main()
{
    vector<thread> threads;
    for(int i = 0; i < 1000; i++) {
        threads.push_back (thread (foo));
    }
    for (auto& t : threads) t.join();

    cout << u << endl;
    return 0;
}

次の行でコンパイルされますg++ -Wall -fexceptions -g -std=c++14 -c main.cpp -o main.o。

1000を出力しますが、これは正しいです。ただし、以前にインクリメントされた値をスレッドが上書きするため、数は少なくなると予想していました。なぜこのコードは相互アクセスの影響を受けないのですか？

私のテストマシンには4つのコアがあり、私が知っているプログラムには制限を設けていません。

共有のコンテンツをfooもっと複雑なものに置き換えても問題は解決しません、例えば

if (u % 3 == 0) {
    u += 4;
} else {
    u -= 1;
}

foo()非常に短いため、各スレッドはおそらく次のスレッドが生成される前に終了します。のfoo()前にランダムな時間スリープを追加すると、u++期待どおりの結果が得られる場合があります。

競合状態はコードが正しく実行されないことを保証するものではないことを理解することが重要です。これは、未定義の動作であるため、コードが何でも実行できるということです。期待どおりの実行を含みます。

特にX86およびAMD64マシンでは、命令の多くがアトミックであり、一貫性の保証が非常に高いため、競合状態がまれに問題を引き起こすことはほとんどありません。これらの保証は、多くの命令をアトミックにするためにロックプレフィックスが必要なマルチプロセッサシステムでは多少低下します。

マシンのインクリメントがアトミック操作である場合、言語標準によれば、未定義の動作であるにもかかわらず、これはおそらく正しく実行されます。

特にこの場合、コードはアトミックなFetch and Add命令（X86アセンブリではADDまたはXADD）にコンパイルされる可能性がありますが、シングルプロセッサシステムではアトミックですが、マルチプロセッサシステムでは、アトミックおよびロックであるとは限りません。そうすることを要求されるでしょう。マルチプロセッサシステムで実行している場合は、スレッドが干渉して誤った結果を生成する可能性のあるウィンドウが表示されます。

具体的には、httpsfoo()：//godbolt.org/を使用してコードをアセンブリにコンパイルし、次のようにコンパイルします。

foo():
        add     DWORD PTR u[rip], 1
        ret

これは、シングルプロセッサではアトミックになる追加命令を単独で実行していることを意味します（マルチプロセッサシステムではそうではありません）。

前後に睡眠をとれば、そんなに大したことはないと思いますu++。むしろ、操作u++は、呼び出しfooを行うスレッドの生成のオーバーヘッドと比較して、インターセプトされる可能性が低いように非常に迅速に実行されるコードに変換されます。ただし、操作を「延長」u++すると、競合状態が発生する可能性が高くなります。

void foo()
{
    unsigned i = u;
    for (int s=0;s<10000;s++);
    u = i+1;
}

結果： 694

ところで：私も試しました

if (u % 2) {
    u += 2;
} else {
    u -= 1;
}

そして、それはほとんどの1997場合私に与えましたが、時には1995。

それは競合状態に苦しんでいます。usleep(1000);前u++;に置くfooと、毎回異なる出力（<1000）が表示されます。

1. 競合状態が存在するにもかかわらず、競合状態が現れなかった理由として考えられる答えはfoo()、スレッドを開始するのにかかる時間に比べて非常に速いため、各スレッドが終了してから次のスレッドが開始されることさえあります。だが...

2. 元のバージョンでも、結果はシステムによって異なります。私は（クアッドコア）Macbookで試してみましたが、10回の実行で、1000が3回、999が6回、998が1回取得されました。そのため、レースはややまれですが、明らかに存在します。

3. でコンパイルしましたが'-g'、これにはバグをなくす方法があります。私はあなたのコードを再コンパイルしましたが、まだ変更されていませんが、はありませんでした。'-g'レースはさらに顕著になりました。1000を1回、999を3回、998を2回、997を2回、996を1回、992を1回取得しました。

4. 再 スリープを追加することの提案-それは役立ちますが、（a）一定のスリープ時間は、スレッドが開始時間（タイマーの解決に応じて）によって歪められたままになります、そして（b）ランダムなスリープは、必要なときにスレッドを広げますそれらを互いに近づけます。代わりに、開始信号を待つようにコードを記述します。これにより、すべてを作成してから作業を開始できます。このバージョン（の有無にかかわらず'-g'）では、974から998以下のすべての場所で結果が得られます。

   #include <iostream>
   #include <thread>
   #include <vector>
   using namespace std;
   
   unsigned u = 0;
   bool start = false;
   
   void foo()
   {
       while (!start) {
           std::this_thread::yield();
       }
       u++;
   }
   
   int main()
   {
       vector<thread> threads;
       for(int i = 0; i < 1000; i++) {
           threads.push_back (thread (foo));
       }
       start = true;
       for (auto& t : threads) t.join();
   
       cout << u << endl;
       return 0;
   }