分析很透彻的C/C++ 基本类型及是否需要多线程锁

学了C然后C++，然后MFC/Windows,然后是C#,其中数据类型很多，由基本类型衍生的typedef类型也N多。熟知基本数据类型是我们正确表达实际问题中各种数据的前提，因此我分类总结了一下C/C++/Windows /C#基本数据类型，以便日后查阅。

         ANSI C/C++基本数据类型32位机器上：

Type	Size	数值范围
无值型void	0 byte	无值域
布尔型bool	1 byte	true   false
有符号短整型short [int] /signed short [int]	2 byte	-32768~32767
无符号短整型unsigned short [int]	2 byte	0~65535
有符号整型int /signed [int]	4 byte	-2147483648~2147483647
无符号整型unsigned [int]	4 byte	0~4294967295
有符号长整型long [int]/signed long [int]	4 byte	-2147483648~2147483647
无符号长整型unsigned long [int]	4 byte	0~4294967295
long long	8 byte	0~18446744073709552000
有符号字符型char/signed char	1 byte	-128~127
无符号字符型unsigned char	1 byte	0~255
宽字符型wchar_t (unsigned short.)	2 byte	0~65535
单精度浮点型float	4 byte	-3.4E-38~3.4E+38
双精度浮点型double	8 byte	1.7E-308~1.7E+308
long double	8 byte

说明：

 

（1）类型修饰符signed和unsigned用于修饰字符型和整形。

（2）类型修饰符short和long用于修饰字符型和整形。

（3）当用signed和unsigned、short和long修饰int整形时，int可省略。

（4）其中bool和wchar_t是C++特有的。

（5）除上表以外，C/C++都可以自定义枚举enum、联合union和struct结构体类型。

（6）以上sizeof通过Windows XP 32位平台测试，其中某些类型数据的字节数和数值范围由操作系统和编译平台决定。比如16位机上，sizeof(int) = 2，而32位机上sizeof(int) = 4；32位机上sizeof(long) = 4，而64位机上sizeof(long) = 8。除此之外，注意64位机上的pointer占8byte。

（7）void的字面意思是“无类型”，不能用来定义变量。void真正发挥的作用在于：<1> 对函数返回和函数参数的限定，例如自定义既不带参数也无返回值的函数void MyFunc(void);<2>定义无类型通用指针void *，指向任何类型的数据。

（8）标准C++库及STL还提供了通用数据结构：字符串类string；向量类模板vector；双端队列类模板deque；链表类模板list；容器适配器堆栈类stack（实现先进后出的操作）；容器适配器队列类queue（实现先进先出的操作）；集合类set；多重集合类multiset；映射类map；多重映射类multimap；位集合bitset；迭代器iterator (类似指针的功能,对容器的内容进行访问)。

（9）在标准c++中，int的定义长度要依靠你的机器的字长，也就是说，如果你的机器是32位的，int的长度为32位，如果你的机器是64位的，那么int的标准长度就是64位，而vc中__int64是为在32机位机器长实现64位长度的整形数。

（10）关于32位平台下的int和long

long从字面上看，应该是64位才更合理，把long当成32位实在是一个历史的包袱。像C#那样新起炉灶的程序语言，由于没有需要支持老代码的问题，就把long当作64位来处理了。

在32位平台下，long是相对short而言，long（short）类型是long（short） int类型的简称，sizeof(long) = sizeof(int) = 4。int和long的范围虽然一样,但输入输出格式不同,printf int的格式为%d，而printf long的格式为%ld。

考虑到程序的可移植性，还是要将他们区分开来。但当要求的数值范围为4byte时，建议使用int类型，因为第一版的C语言只有一种类型，那就是int。

（11）在Win32 API及MFC中为了使类型名称在语意上更明了，对以上基本类型进行了大量的typedef。例如WINDEF.H中的BYTE,WORD,DWORD。

（12）计算机内部内存的基本单位是1byte(8个电子开关)！

http://blog.csdn.net/scucj/article/details/3479829 

背景：如果有一个类型为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发生变化而影响这些操作，这种情况下，就需要加锁。 加锁的目的是为了保护数据，如果不需要保护的情况下数据就本身就可以一致，就没有必要加锁, 啰嗦了:)。

http://topic.csdn.net/u/20101217/14/05CB2E93-03E9-4F77-BE65-9241393C1DF3.html

对于多线程访问同一变量是否需要加锁的问题，先前大家都讨论过。今天用代码验证了一下之前的猜想: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