CPU乱序发射与内存屏障

#include <stdio.h>
#include <pthread.h>
int x = 0, y = 0;
void* mythread1(void*)
{

    while (y == 0)
    {
    }
    printf("x=%d\n",x);
}

void* mythread2(void*)
{
    x = 1;
    y = 1;
}

int main()
{
    int ret = 0;
    pthread_t id1, id2;
    ret = pthread_create(&id1, NULL, mythread1, NULL);
    if (ret)
    {
        printf("create pthread error!\n")；
        return -1;
    }
    ret = pthread_create(&id2, NULL, mythread2, NULL);
    if (ret)
    {
        printf("create pthread error!\n");
        return -1;
    }
    pthread_join(id1, NULL);
    pthread_join(id2, NULL);
    return 0;
}

阅读代码可知程序的输出为x=1，因为在对y赋值之前已对x赋值，所以当线程1跳出循环时x=1是不奇怪的。实际运行这段代码时，程序的输出也确实为1，即使测试了10000次，也没出现其他结果。但能出现正确结果真的是因为代码中赋值顺序吗？
实际上并不是，程序能输出正确结果仅仅是因为线程分配到的时间片过长&&线程需要执行的时间过短
对于线程2而言，执行时间大约等于访问两次内存的时间，约等于50ns，而线程分配的时间片为ms级别。所以程序并没有出现异常的结果。但是相信程序的执行顺序与代码的编写顺序一致是一种危险的观点。实际上如果两个语句之间不存在数据相关，由于编译器的乱序优化和CPU的乱序执行，语句的执行顺序是不确定。CPU乱序执行只保证局部的正确性（数据相关的语句一定按原顺序执行）

a = x + y;	//语句1
c = a + b;	//语句2
// 语句2一定在语句1之前执行
m = p + q;	//语句3
k = i + j;	//语句4
//语句3不一定在语句4之前执行

设想一个极端情况，在执行语句3时，访问变量p时cache未命中且发生缺页，此时语句4大概率在语句3之前执行完毕。为使语句执行顺序与代码顺序保持一致，有两种解决思路。
一：增加冗余的数据相关

m = p + q;	
k = i + j + m;	
k -= m;

这种方法是我瞎想的，不知道会不会被编译器优化掉，(^__) 嘻嘻……
二：增加内存屏障
Barrier函数可以在代码中设置屏障，这个屏障可以阻挡编译器的优化，也可以阻挡处理器的优化。

对于编译器来说，设置任何一个屏障都可以保证：

编译器的乱序优化不会跨越屏障，即屏障前后的代码不会乱序；

在屏障后所有对变量或者地址的操作，都会重新从内存中取值（相当于刷新寄存器中的变量副本）。

而对于处理器来说，根据不同的屏障有不同的表现（以下仅仅列举3种最简单的屏障）：

读屏障rmb()
处理器对读屏障前后的取数指令（LOAD）能保证有序，但是不一定能保证其他算术指令或者是写指令的有序。对于读指令的执行完成时间也不能保证，即它不能保证在屏障之前的读指令一定都执行完成，只能保证屏障之前的读指令一定能在屏障之后的读指令之前完成。

写屏障wmb()
处理器对屏障前后的写指令（STORE）能保证有序，但是不一定能保证其他算术指令或者是读指令的有序。对于写指令的执行完成时间也不能保证，即它不能保证在屏障之前的写指令一定都执行完成，只能保证屏障之前的写指令一定能在屏障之后的写指令之前完成。

通用内存屏障mb()
处理器保障只有屏障之前的访存操作（包括读写）都完成以后才会执行屏障之后的访存操作。即可以保障读写之间的有序（但是同样无法保证指令完成的时 间）。这种屏障对处理器的执行单元效率产生的负面影响要比单纯用读屏障或者写屏障来的大。比如对于PowerPC来说这种通用屏障通常是使用sync指令实现的，在这种情况下处理器会丢弃所有预取的指令并清空流水线。所以频繁使用内存屏障会降低处理器执行单元的效率。

对于驱动开发者来说，一些对设备寄存器的操作，通常是必须保证有序的。在绝大部分情况下，一般都是写操作。对于有序的写操作，必须设置写屏障（wmb)。

当程序出现随机性的问题时，在随机的部分找原因

参考博客：CPU乱序执行