单线程读 单线程写一个变量是否一定要加锁

单线程读单线程写一个变量是否需要加锁，刚毕业的时候我会有这样的想法：一个线程只读并没有改变变量的值并不会有两个线程同时写一个变量产生竞态，所以不用加锁，但是工作中长者给我指导都是多线程必须加锁，所以我也没有深究这个问题，从来没有想过为什么。

　　过了一段时间后，了解到原子性这个概念，了解到虽然一个线程读一个线程写，但是因为对一个线程的写和读并非是原子的，读线程可能读到另外一个线程写到一半的值，所以要加锁来保护。但是上面的答案直到我看到下面的文章再一次被推翻了。

　　关于这个观点我也写了个测试发现结果是正确的（因为我测试环境是64位所以char,int,long读写都是原子的）

 
//  Created by 杜国超 on 19/8/25.
//  Copyright © 2019年 杜国超. All rights reserved.
//
 
#include <memory>
#include <iostream>
#include <thread>
#include <atomic>
#include <zconf.h>
#include <vector>
#include <algorithm>
 
using namespace std;
 
char c_v = 0;
int i_v = 0;
long long l_v = 0;
float f_v = 0.0f;
 
std::atomic_bool flag(true);
 
void thread_func1() {
    while (flag)
    {
        c_v = '1';
        i_v = 111111111;
        l_v = 111111111;
        f_v = 1111.11111;
        usleep(1);
    }
}
 
void thread_func2() {
    while (flag)
    {
        c_v = '2';
        i_v = 222222222;
        l_v = 222222222;
        f_v = 2222.22222;
        usleep(1);
    }
}
 
void thread_func3() {
    while (flag)
    {
        char tmpc = c_v;
        if(!(tmpc == '1' || tmpc == '2'))
        {
            printf("char value read error %c\n",tmpc);
        }
 
        int tmpi = i_v;
        if(!(tmpi == 111111111 || tmpi == 222222222))
        {
            printf("int value read error %d\n",tmpi);
        }
 
        long tmpl = l_v;
        if(!(tmpl == 111111111 || tmpl == 222222222))
        {
            printf("long value read error %ld\n",tmpl);
        }
 
        float tmpf = f_v;
        if(!(tmpf == 1111.11111 || tmpf == 2222.22222))
        {
            printf("float value read error %f\n",tmpf);
        }
        usleep(1);
    }
}
 
int main() {
    std::vector<thread> threads;
    for(int i = 0 ;i < 50 ; i++)
    {
        threads.push_back(std::move(std::thread(thread_func1)));
    }
    for(int i = 0 ;i < 50 ; i++)
    {
        threads.push_back(std::move(std::thread(thread_func2)));
    }
    std::thread check_thread(thread_func3);
    std::for_each(threads.begin(),threads.end(),[](std::thread& th) {th.join();});
    check_thread.join();
    return 0;
}

　其实对于上面的问题有一个很好的解释就是：锁本身也是一个基本类型，如果锁的读写不是原子的，那谁来保证锁的线程安全，给锁再加个锁吗。

　　这样新的疑问诞生了，既然char,bool,int,读写是原子的，为什么也要加锁。关于这个问题又很多个关键点，首先是仍然是原子性问题比如a++，这个操作并非原子的如果两个线程同时进行这个操作可能会导致操作的丢失，所以如果多线程写没有争论必须要加锁或者使用atomic相关的操作来保证线程的安全性。不过我们这里讨论的是单线程读单线程写是否要加锁，对于非上面提到的基本了类型由于原子性的限制必须保证不能让多线程读到写线程写到一半的值所以必须要加锁。

　　保证了原子性后还有一个可见性问题，写线程改变了变量的值读线程不一定能够立马读到改变后的值，但是如果我们可以接受这种延时读取完全可以不做任何额外的处理（比如我们一个值表示当前的池子中的水位，我们写线程加水后把表示水位的值改变为新的状态我们读线程取水，这次取不到可以下次取），当然这个问题也可以通过voliate关键字来解决,最暴力的手段当然还是加锁。在我们可以保证了可见性之后还有一个比较头疼的问题就是cpu执行时的乱序问题，cpu乱序执行分为两个维度。第一个维度的乱序是对于不相干的计算乱序执行。譬如

MUL R1, R2
ADD R3, R4

乘法比加法需要更多的cycle，而这两个指令操作的寄存器没有任何依赖关系，所以可以乱序执行，不必等待MUL执行完以后再执行ADD。第二个维度是memory reordering。具体什么样的规则取决于硬件的内存模型。Intel x64的基础是一种叫做total store ordering（TSO）的模型，大概可以理解为，除了store-load可以reorder以外，其他的都不可以。就是说如果一个store先执行了然后是一个load，他们操作的地址也不同，就可以reorder。这样设计的目的主要是为了掩盖store的latency。具体的实现则是在CPU和缓存之间加一个store buffer（揭开内存屏障的面纱），store发生以后被放到store buffer，从store buffer出来以后才能对其他核可见（visible），来保证，最暴力的手段当然还是加锁。如果你并没有类似的依赖逻辑就是单纯的一个线程读，一个线程写，对于上面提到几一些基本变量你完全可以不做任何处理更不需要加锁。

//

对于多线程访问同一变量是否需要加锁的问题，先前大家都讨论过。今天用代码验证了一下之前的猜想:32位CPU与内存的最小交换数据为4字节/次，这也是结构体要对齐4字节的原因。在物理上，CPU对于同一4字节的内存单元，不可能写2个字节的同时，又读了3字节。

测试环境为：

XEON 2CPU*2

Windows7

采用50,50,50线程交叉读写，试验代码如下：

C/C++ code

int g_test;

int temp;

BOOL g_bRunning;

DWORD WINAPI thWriteProc1(LPVOID lParam)

{

    while(g_bRunning)

    {

        g_test = 12345678;

        Sleep(1);

    }

    return 0;

}

DWORD WINAPI thWriteProc2(LPVOID lParam)

{

    while(g_bRunning)

    {

        g_test = 13579246;

        Sleep(1);

    }

    return 0;

}

DWORD WINAPI thReadProc(LPVOID lParam)

{

    while(g_bRunning)

    {

        temp = g_test;//读取值

        if ( temp != 12345678 && temp != 13579246 )

        {

            g_bRunning = FALSE;

            CString str;

            str.Format("read error!%d", temp);

            AfxMessageBox(str);

            break;

        }

        Sleep(1);

    }

    return 0;

}

void CTestMultiyAccessIntDlg::OnButton1() 

{

    g_bRunning = TRUE;

    for ( int i = 0; i < 50; i++ )

    {

        //创建50个写线程1

        CreateThread( NULL, 0, thWriteProc1, NULL, 0, NULL );

    }

    for ( int i = 0; i < 50; i++ )

    {

        //创建50个写线程2

        CreateThread( NULL, 0, thWriteProc2, NULL, 0, NULL );

    }

    for ( int i = 0; i < 50; i++ )

    {

        //创建50个读线程

        CreateThread( NULL, 0, thReadProc, NULL, 0, NULL );

    }

}

测试方法：

改变g_test的类型，给g_test赋予不同的值(不要超过类型的上限值)

测试现象：

当g_test为int,short char时，不存在多线程交叉读写错误的问题

当g_test为double, float, __int64时，存在多线程交叉读写错误的问题，对于__int64，当赋值小于0xFFFFFFFF时不出错，当大于0xFFFFFFFF时出错

当g_test为CString时，存在交叉读写错误，有时候程序崩溃

另：不加Sleep(1)机器卡死过，CPU占用率达到100%，4个核心占用率全满，可以保证运行在多核环境下

现象分析：

(1)int short char均为小于4字节的连续内存块，CPU一条指令就可以读写它们的值，CPU不可能同一个时间执行两条指令

(2)double为8字节，如果写线程先写了4字节，读线程读了8字节，这自然导致数据被破坏

(3)float也为4字节，我也不是太清楚为什么不行，可能是VC对浮点数的处理比较特殊有关，浮点数具有复杂内存结构

(4)__int64为8字节，存在和(2)相同的情况，如果__int64小于等于0xFFFFFFFF，相当于只改变了低4字节，因此就没有问题

(5)CString为类类型，具有复杂结构，显然不行

结论：

1.对于int,short,char,BOOL等小于等于4字节的简单数据类型，如果无逻辑上的先后关系，多线程读写可以完全不用加锁

2.尽管float为4字节，多线程访问时也需要加锁

3.对于大于4字节的简单类型，比如double,__int64等，多线程读写必须加锁。

4.对于所有复杂类型，比如类，结构体，容器等类型必须加锁

尽管对int等类型的多线程读写不需要加锁，但是逻辑上有必要加锁的还是应该加锁

例如：对于一个多线程访问的全局变量int g_test

int count = g_test/1024;

int mod = g_test24;

由于是两条语句，执行完第一条之后，别的线程很可能已经修改了g_test的值，如果希望这两条语句执行时，g_test不发生变化，就必须加锁，以保证两条语句执行的整体性。

Lock();

int count = g_test/1024;

int mod= g_test24;

UnLock();

如果不加锁，也可以改为先保存到一个临时变量里

int temp = g_test;

int count = temp/1024;

int mod = temp24

///

        背景：如果有一个类型为int的全局变量a, 线程A对a仅进行读操作，线程B对a仅进行写操作，那么两个线程在操作a时是否需要加锁来保持同步呢?

        这个不能简单判断一定要加锁或是不加锁。要分情况讨论。

       

        情况一：如果线程A读取a的目的仅为了显示给界面，或者a满足一定条件后执行某些操作，而在执行这些操作过程中对a是否发生了变化并不关心；一定间隔时间后又同样执行上述操作。这种情况下，就不需要加锁。

       

        理由是，线程A对a进行读取时是完整的读取的，同样线程B对a写也是完成写的；不存在对a读一半或写一半的问题。可能又有新的疑问，这样且不是说对a的操作是原子了，那样的话何必还需要原子变量的类型了，而且对a的操作也不是一条指令能完成的啊。其实这个疑问和“不存在对a读一半或写一半”的说法并不矛盾。因为“不存在对a读一半或写一半”并不是说对a的操作就是原子操作。对写举个例子，a = a + 1, 这个操作毫无疑问肯定不是原子操作。这个语句简单的转换为类似机器语言，第一步，把a读取到一个寄存器中，第二步将寄存器中的值加1，第三步将寄存器中的新值写入a中。既然需要三步操作了，显然就不是原子操作了，那么“不存在对a读一半或写一半”的意思是什么呢？它的意思就是说第二步是一次执行成功的。换句话说，线程B要写a，做了三步操作中任何一步结束，线程A去读a，a仍是一个有效值，只不过a并不一定是一个最新的值。情况一中线程A并不关心a是不是最新的值，只关心a是否由线程B写入的一个合法值就可以了，至于最新值可以通过循环去不断刷新。 也许有人还有疑问，为什么第二步是一次执行成功的呢？难得就不可能执行一半就被其他线程抢去CPU了吗？这个不会，因为有了字节对齐，一个读周期或是一个写周期仅需要一个总线周期，在这个总线周期内就把这个整型变量给处理了, 一个总线周期结束前CPU不会被抢占，就是中断发生也不会导致一个总线周期执行一半时CPU被抢占(CPU是在现行指令结束后响应中断，即运行到最后一个指令周期中的最后一个总线周期中的最后一个T状态时CPU才采样INTR线来查看是否有中断请求)。

        情况二：线程A对a仅进行读操作，然后对a进行判断后执行相应的操作，如果这个过程中由于线程B对a进行写操作导致a发生变化而影响这些操作，这种情况下，就需要加锁。

        加锁的目的是为了保护数据，如果不需要保护的情况下数据就本身就可以一致，就没有必要加锁, 啰嗦了:)。

//

关于这个问题，很少有听到权威的解答。偶这里也只是收集各处资料，以尝试对今后写出高质量的代码做一定的保证。

通常会联想到这个问题应该跟CPU架构相关。CSDN上也有人做了实验。根据其结论，在x86上，对1字节byte/2字节word/4字节int类型的读写操作都是原子性的。（类似java中的immutable objects的概念）亦即，1个int不会有中间状态，若它原始值是0，往其写入0x12345678，则另一个线程绝对不会读到0x12000000或是0x00005678的值。

根据偶自己的实验，不但int是原子的，在64位x86上，size_t(8字节)也是原子操作（多核，volatile）。

注意：

1. 通常偶们会以为64位系统中的int是64位的，但实际上不一定，请参见ABI这个概念，简单说就是gcc用-m64参数编译，不加其它选项的话，其int为32位，long也为32位，只有long long, size_t为64位。

2. 根据编译器优化选项不同，以上结论有可能被颠覆：一个64位类型的赋值有可能被编译器编译为两个32位的指令。请在实验时看好自己的编译器(确认反汇编 ^_^)

但是，从收集的资料来看，结果是令人沮丧的。要实现在各种CPU上都通用的原子操作，bool/int都没有得到标准的支持。

写一个字节也不安全？请见下面链接：

http://stackoverflow.com/questions/15246862/single-byte-write-by-multiple-threads-in-smp-without-using-lock

主要意思如下：有的架构如Alpha等，根本就没办法实现不读原始值而写1个byte

C++标准也没有规定bool/int类型变量的原子性：

http://stackoverflow.com/questions/4936289/is-volatile-a-proper-way-to-make-a-single-byte-atomic-in-c-c

所以C++0x中做出了规定。

有没有绝对支持的平台？在SMP架构的多核CPU环境下，如果读写指令能够编译成1条指令的话，根据其标准，byte和cache line对齐的int/short应该是原子操作：

http://en.wikipedia.org/wiki/Symmetric_multiprocessing

("ram access are serialized")

http://www.blachford.info/computer/articles/bigcrunch1.html

其中的The problem with cache部份

那么，以后是不是bool/int都要加锁了？这个问题偶也没办法回答。大家视情况而定吧。


增注：
本文讨论的是C/C++中int/bool写法的原子性，并非针对特定CPU。若程序目标平台一定是Intel CPU，可参考其架构手册《64-ia-32-architectures》。
摘抄一段如下：
The Intel486 processor (and newer processors since) guarantees that the following basic memory operations will
always be carried out atomically:
• Reading or writing a byte
• Reading or writing a word aligned on a 16-bit boundary
• Reading or writing a doubleword aligned on a 32-bit boundary
The Pentium processor (and newer processors since) guarantees that the following additional memory operations
will always be carried out atomically:
• Reading or writing a quadword aligned on a 64-bit boundary
• 16-bit accesses to uncached memory locations that fit within a 32-bit data bus
The P6 family processors (and newer processors since) guarantee that the following additional memory operation
will always be carried out atomically:
• Unaligned 16-, 32-, and 64-bit accesses to cached memory that fit within a cache line
翻译一下最后一段就是说，在P6以上CPU不管有没有进行对齐，只要访问的word/dword/qword所有字节都在cache line内部，就是原子操作。
cache line对齐大小可用以下命令获得：
# cat /proc/cpuinfo
cache_alignment : 64

当然你仍然要记住你写的是C/C++代码，将来它运行的架构并非确定的，所以不能无视C/C++标准。

//

大神回答：

多线程，只要至少一个线程在写，原则上都要加锁。 什么情况下不需要加锁？基本数据类型的读写，且不需要考虑数据一致性的时候。