为什么 一个线程读数据，一个线程写数据，要加锁？
为什么 一个线程读数据，一个线程写数据，要加锁？


这种奇怪的言论，不知道为什么会出现?



随手举个例子



全局变量int g_val;



线程1
｛

printf("%d",g_val);

｝


线程2
｛
g_val++;

｝


显然不需要 加锁啊。 多个线程修改数据，那么则需要加锁，如果只是一个读，一个写，加锁作甚？




问题2：

典型的读写者模型： 多个线程读，多个线程写。


http://blog.csdn.net/morewindows/article/details/7596034问中提到的这个模型

与上一篇《秒杀多线程第十篇 生产者消费者问题》的生产者消费者问题一样，读者写者也是一个非常著名的同步问题。读者写者问题描述非常简单，

有一个写者很多读者，多个读者可以同时读文件，但写者在写文件时不允许有读者在读文件，同样有读者在读文件时写者也不去能写文件。


问：为什么要如此规定。读的时候不能写，写怎么了？影响数据？ 还是怎地？写的时候，不能读？读有如何。

这种规定的模型真不知道是如何提出来的。





[解决办法]
如果你读写一个bool，那么我想它的所有操作应该都是原子操作，多少个线程分别读写都不需要加锁
如果你读写一个double——嗯，你想想32位环境下8字节浮点数的操作能不能都用一条汇编指令完成吧
[解决办法]
简单类型比如整形，bool，之类的，如果只有一个线程进行写操作，确实是不需要加锁的，目前主流的cpu都支持内存操作的原子性。也就是说一个整形变量，假如写之前的值是0xaaaaaaaa,写入的值是0xbbbbbbbb,这个变量的值要么是0xaaaaaaaa，要么是0xbbbbbbbb。绝不可能是其他值。

但这只是针对简单类型而言，结构体什么的肯定就需要加锁了。比如楼主的那个例子，只有一个写线程，但是写线程操作的是文件，这个就肯定需要加锁了。

而即使是简单类型，如果有多个写线程，写线程之间是肯定会有竞争问题的，这个也需要加锁。




[解决办法]
锁不是用来保证执行顺序的，建议先去打听一下再出来。
[解决办法]
加不加锁，要看你是否需要保证你写线程中所有对共享变量的操作是否需要原子化而定。如果你不需要，就是这个操作的中间值你也可以接受，那么就加不加无所谓了。
[解决办法]
30楼正解，不加锁可能导致脏数据，但是如果你认为暂时的脏数据是可以接受的，那么不加也行。
[解决办法]