并发编程（一）多线程存在的问题

经典案例：因为cache一致性问题而导致的多线程问题

#include <thread>
#include <iostream>
int main() {
    constexpr long N = 10000000;
    long sum = 0;
    std::thread t1([&](){
        for(int i=0; i<N; ++i) {
            sum++;
        }
    });
    std::thread t2([&](){
        for(int i=0; i<N; ++i) {
            sum++;
        }
    });
    t1.join();
    t2.join();
    std::cout << sum << std::endl;
}

考虑上述代码，在单线程下，程序执行正常，但是在并发环境中，对sum的++就会出现意想不到的结果，sum的和不是10000000。

更近一步，因为sum++ 在汇编层面不是一条指令，那么强制使用一条指令来进行sum++呢？代码如下：

#include <thread>
#include <iostream>
int main() {
    constexpr long N = 10000000;
    long sum = 0;
    std::thread t1([&](){
        for(int i=0; i<N; ++i) {
            // 强制使用一条指令来执行 sum++
            asm volatile(
                "incq %0" : "+m"(sum)
            );
        }
    });
    std::thread t2([&](){
        for(int i=0; i<N; ++i) {
            asm volatile(
                "incq %0" : "+m"(sum)
            );
        }
    });
    t1.join();
    t2.join();
    std::cout << sum << std::endl;
}

会发现，依旧不会得到正确的sum。

当两个线程在一个cpu核中进行调度，上面的代码会得到正确的值，因为asm volatile( “incq %0” : “+m”(sum)); 只是一条指令，每次对sum的操作都是原子的。

但是，当两个线程分别在不同的cpu核中执行，可能就连一条指令的原子性都可能无法保证（每个cpu都有L1缓存，还有受到Store Buffer影响，对于共享变量，一个cpu核执行完后的结果，并不能立马被cpu另外核感知到）。

所以，对于并发，讲概念，甚至讲代码，都是不够的，需要从数学的视角， 证明该并发逻辑的正确性。

经典案例：指令重排

编译器在优化代码时，会假设该程序是单线程的，即编译器只保证不管如何优化，在单线程场景下，代码优化前和优化后的执行结果是相同的，所以通常一些优化操作，会将指令重排（汇编层面），这在单线程下可以提升性能，且保证正确性；但引入多线程后，一切就变的不可预知。编译器会试图优化状态迁移，改变执行流。

比如，还是上面的那份代码，简化一下：

/*
 * @Author: YAFree yafree123@163.com
 * @Date: 2024-03-28 22:51:37
 * @LastEditors: YAFree yafree123@163.com
 * @LastEditTime: 2024-04-03 02:56:00
 * @FilePath: /taskflow/demo/simple.cpp
 * @Description: 这是默认设置,请设置`customMade`, 打开koroFileHeader查看配置 进行设置: https://github.com/OBKoro1/koro1FileHeader/wiki/%E9%85%8D%E7%BD%AE
 */
#include <thread>
#include <iostream>


constexpr long N = 10000000;
long sum = 0;
void T_sum() {
    for(int i=0; i<N; ++i) sum++;
}
int main() {
    std::thread t1(T_sum);
    std::thread t2(T_sum);
    t1.join();
    t2.join();
    std::cout << sum << std::endl;
}

使用debug模式进行编译，T_sum 函数如下：

T_sum():
        push    rbp
        mov     rbp, rsp
        mov     DWORD PTR [rbp-4], 0
        jmp     .L11
.L12:
        mov     rax, QWORD PTR sum[rip]
        add     rax, 1
        mov     QWORD PTR sum[rip], rax
        add     DWORD PTR [rbp-4], 1
.L11:
        cmp     DWORD PTR [rbp-4], 9999999
        jle     .L12
        nop
        nop
        pop     rbp
        ret

几乎就是上述C++代码的直译，算从 0 到 9999999 的整数之和，并将结果存储在名为 sum 的变量中。
上述代码在这种优化级别编译，最终执行结果大概率都是非常随机的值：比如：10291506、9592434等。

而如果开启O1优化:

T_sum():
        mov     rdx, QWORD PTR sum[rip]
        lea     rax, [rdx+1]
        add     rdx, 10000001
.L3:
        mov     rcx, rax
        add     rax, 1
        cmp     rax, rdx
        jne     .L3
        mov     QWORD PTR sum[rip], rcx

开了O2优化以后：

T_sum():
        add     QWORD PTR sum[rip], 10000000
        ret

O2优化后的代码执行时，sum的值在绝大部份时间都是对的，因为T_sum被优化成了一条指令，两个线程的执行流很难遇到冲突的情况（不代表不会），所以绝大部分时间，结果都是对的，但是，这并不代表这段代码线程安全，这也是并发编程的困难之处，光靠代码，也很难确定是否符合设计预期。

经典案例： 死循环

考虑下面代码：

#include <thread>
#include <iostream>


bool flag = false;
void producer() {
    printf("profucer\n");
    flag = true; // B
}
void consumer() {
    while(!flag); // A
    printf("consumer\n");
}

int main() {
    std::thread t1(producer);
    std::thread t2(consumer);
    t1.join();
    t2.join();
}

如上所说，编译器是站在单线程的视角下优化的代码，所以对于A行，开启优化后，编译器可能会将其优化为：判断flag是否为true，如果是，继续执行，如果不是，死循环。

对于单线程来说，这当然正确，因为单线程场景下，flag的值是不会在死循环中被修改的，所以编译器的优化思路正确，但是对于并发场景，这个优化，就会导致代码死循环，即便 B行修改了flag的值，A依旧会死循环。

而在O2优化中，consumer甚至可能优化成：

.LC1:
        .string "consumer"
consumer():
        mov     edi, OFFSET FLAT:.LC1
        jmp     puts

直接输出，所以，在并发编程中，对于代码执行逻辑，不要作假设，因为很大概率，是不符合预期的。

同时，不同平台由于硬件设计不同，在面临不同的并发问题时也会有不同的表现（x86与arm）。

参考

https://www.bilibili.com/video/BV1jx4y1S7cP/?spm_id_from=333.880.my_history.page.click