（转）关于volatile和原子操作研究的插曲

最新推荐文章于 2021-12-05 18:02:20 发布

GoatYangYang

最新推荐文章于 2021-12-05 18:02:20 发布

阅读量1.1k

点赞数

分类专栏： C/C++ 文章标签：编译器优化 thread attributes 多线程 winapi

C/C++ 专栏收录该内容

8 篇文章 0 订阅

订阅专栏

链接地址：http://hi.baidu.com/chenzhuoyou/blog/item/ff65da1327a6c50a5aaf53e8.html

---------------------------------------------------------------------------------------------------------------------

所谓原子操作,就是"不可中断的一个或一系列操作" , 在确认一个操作是原子的情况下，多线程环境里面，我们可以避免仅仅为保护这个操作在外围加上性能昂贵的锁，甚至借助于原子操作，我们可以实现互斥锁。

很多操作系统都为int类型提供了+-赋值的原子操作版本，比如 NT 提供了 InterlockedExchange 等API， Linux/UNIX也提供了atomic_set 等函数。

前两天有同学问我:在x86上，g_count++ （int类型) 是否是一个原子操作? 我的回答是"不是的, 多个CPU的机器(SMP)上面这就不是原子操作"。

今天想起，在单CPU上这个是否是原子操作呢，但是这个和编译器有关，编译器可能有两种编译方式:

A. 多条指令版本，这就不是原子的

MOV 寄存器 , g_count

ADD 寄存器, 1

MOV g_count , 寄存器

B. 单指令版本，这在单CPU的x86上就是原子的

INC g_count

只能写程序验证了, 让5个线程每个对 g_count++ 一亿次，假如是原子操作的话，结果应该是5亿：

其实还需要对 g_count 进行volatile声明，防止编译器对这里不适当的优化，为了看看编译器对volatile的处理，我另外做了个volatile版本作为比较。

#include <windows.h>
#include <stdio.h>

int g_count = 0;

DWORD WINAPI ThreadFunc( LPVOID lpParam )
{

    int i;
    printf( "Thread %d start/n", (DWORD*)lpParam );

    for (i=0; i <100000000 ; i++)
        g_count++;

    printf( "Thread %d quit/n", (DWORD*)lpParam );
    return 0;
}

#define THREAD_NUM 5
VOID main( VOID )
{
    DWORD dwThreadId;
    HANDLE hThread;
    int i;

    for (i=0;i<THREAD_NUM;i++)
    {
        hThread = CreateThread(
            NULL,                        // default security attributes
            0,                           // use default stack size
            ThreadFunc,                  // thread function
            (LPVOID)i,                // argument to thread function
            0,                           // use default creation flags
            &dwThreadId);                // returns the thread identifier

        // Check the return value for success.
        if (hThread == NULL)
        {
          printf( "CreateThread failed./n" );
        }
    }

      printf("Press any key after all thread exit.../n");
      getchar();

      printf("g_count %d/n", g_count);

      if (g_count!=THREAD_NUM*100000000)
      {
          printf("ERROR! g_count %d!=%d/n", g_count, THREAD_NUM*100000000);
      }
      getchar();
      //一个随手的程序，就不close handle了
}

volatile的本意是易变的, 它限制编译器的优化，因为CPU对寄存器处理比内存快很多，我想这个程序的没有加上volatile的版本优化以后应该是这样:

MOV 寄存器, g_count
for循环一亿次, 执行 INC 寄存器
MOV g_count, 寄存器

这样，最后g_count的值应该是1亿,2亿,3亿,4亿,5亿的整数，1亿出现的可能性较高。

而加上volatile以后，或者是没有代码优化的版本，都是老老实实对内存加上一亿次，假如不是原子操作的话，最后结果就会比五亿小。

用的是Vc6的cl编译器，我预期的结果是这样的:

++是原子操作	没有代码优化	代码优化(cl -O2编译)
没有 volatile	g_count == 五亿	g_count的值应该是1亿,2亿,3亿,4亿,5亿的整数
volatile	g_count == 五亿	g_count == 五亿

++ 不是原子操作	没有代码优化	代码优化(cl -O2编译)
没有 volatile	g_count < 五亿	g_count的值应该是1亿,2亿,3亿,4亿,5亿的整数,1亿出现的可能性较高
volatile	同上	g_count < 五亿

但是最后的结果却让我大跌了一下眼镜:

VC6实验的结果	没有代码优化	代码优化
没有 volatile	g_count 一般为五亿, 偶尔< 五亿(疑惑中...)	都是五亿(疑惑中...)
volatile	同上(疑惑中...)	g_count = < 五亿(这个可以解释)

这个结果太让人疑惑了，没办法，只能看asm代码了, 首先看看为什么volatile的版本为什么和预期不符合吧:

这里是没有优化的版本（编译命令行 cl -Fa test_thread.c):

for (i=0; i <100000000 ; i++)
初始化i=0;
    mov    DWORD PTR _i$[ebp], 0
    jmp    SHORT $L52751
$L52752: i++
    mov    ecx, DWORD PTR _i$[ebp]
    add    ecx, 1
    mov    DWORD PTR _i$[ebp], ecx
$L52751: 判断 i <100000000
    cmp    DWORD PTR _i$[ebp], 100000000        ; 05f5e100H
    jge    SHORT $L52753
g_count++;
//这里发现编译使用的是多个指令，也就是说g_count++不是原子的
    mov    edx, DWORD PTR _g_count
    add    edx, 1
    mov    DWORD PTR _g_count, edx
    jmp    SHORT $L52752

下面是加了volatile的优化版本（编译命令行 cl -Fa test_thread.c -O2)

    //初始化 i = 100000000, 这个循环变量被直接放到了寄存器里面
    mov    eax, 100000000                ; 05f5e100H
$L52793:
    //g_count++;这里发现编译使用的是多个指令，也就是说g_count++不是原子的
    mov    ecx, DWORD PTR _g_count
    inc    ecx
    mov    DWORD PTR _g_count, ecx
    //下面又是循环体的asm代码
    dec    eax // i--
    jne    SHORT $L52793 // if (i>0) 则继续循环