CSDN论坛争议帖:"C++读写锁"引发一场揪出伪专家的讨论

[作者]
网名: 猪头三
站点: http://www.x86asm.com
Email: pliceman_110@163.com
QQ: 643439947
编程生涯: 2001～至今[10年]
职业生涯: 9年
开发语言: C/C++; x86asm; Object Pascal; C#;
开发工具: VC++; Delphi;
研发领域: Windows应用软件安全; Windows系统内核安全; Windows系统磁盘数据安全;
技能种类: 逆向 驱动 磁盘 文件

[原帖信息]
C++读写锁，难道不用mutex也可以实现么?
http://topic.csdn.net/u/20120611/10/5a777a86-aeab-44e4-9e55-d7ec17add9b1.html

[争论点]
8楼4星级别的网友在贴出了他认为可以实现同步的多线程代码,引发了一场争论.结果被9楼2星级别的网友批评,可是8楼讽刺9楼,我个人觉得8楼网友的态度实在太恶劣了.

//比如一个全局变量int gUse=0;

//线程1：
while (1) {
 if (gUse==0) {
  gUse=1;
  if (gUse==1) {
   //进入临界区
   //...
   gUse=0;//退出临界区
   break;
  }
 }
 Sleep(100);
}

//线程2：
while (1) {
 if (gUse==0) {
  gUse=2;
  if (gUse==2) {
   //进入临界区
   //...
   gUse=0;//退出临界区
   break;
  }
 }
 Sleep(100);
}

[解析争论点]
下面我们来看看这个代码多线程同步的技术含量.我个人主观来说,这段代码是极其危险,从而侧面反映出该8楼4星级别的网友的系统理论极其贫乏.要明白这段代码的多线程同步危险性,必须具备如下系统理论: 线程, 多线程, 同步, 上下文切换, 线程调度, 时间片 这几个应该足够了.下面我来分析这个段代码为什么不能起到同步作用.

1>当2个线程启动时,并且线程1准备执行 gUse=1 , 又并且 线程2也准备执行gUse=2 .
2>这时线程2的运行时间片结束,进入暂停状态(这里用暂停是不正确的术语,我只是说白了), 线程1继续执行后面代码并正常进入临界区.
3>然后线程1的运行时间片结束,进入暂停状态(这里用暂停是不正确的术语,我只是说白了),并且此时线程1没有退出临界区.
4>在然后线程2重新启动继续执行了gUse=2,也顺利进行如临界区.

由此简单的4步,这2个线程已经进入了临界区,如果开发人员在这临界区去操作共享资源,那么将是非常危险的.就好比2个人同时在一个粪坑上大便,很恶心滴.
当然这段代码,还会发生更极端的错误.这个我就不多说了,留给你们自己思考.

[如何解决这个问题呢?]
我建议大家去看这几本书
1> Windows核心编程
2> Win32多线程程序设计
3> Windows并发编程指南