对于“多线程访问同一个变量是不是需要加锁”的研究
对于“多线程访问同一个变量是否需要加锁”的研究
对于多线程访问同一变量是否需要加锁的问题，先前大家都讨论过。今天用代码验证了一下之前的猜想:32位CPU与内存的最小交换数据为4字节/次，这也是结构体要对齐4字节的原因。在物理上，CPU对于同一4字节的内存单元，不可能写2个字节的同时，又读了3字节。
测试环境为：
XEON 2CPU*2
Windows7
采用50,50,50线程交叉读写，试验代码如下：
测试方法：
改变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_test%1024;
对于多线程访问同一变量是否需要加锁的问题，先前大家都讨论过。今天用代码验证了一下之前的猜想:32位CPU与内存的最小交换数据为4字节/次，这也是结构体要对齐4字节的原因。在物理上，CPU对于同一4字节的内存单元，不可能写2个字节的同时，又读了3字节。
测试环境为：
XEON 2CPU*2
Windows7
采用50,50,50线程交叉读写，试验代码如下：
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_test%1024;