关于多线程对同一个文件进行写操作，记得坛子里面讨论过，不需要互斥，原因什么来着？

epegasus

回复 80# 思一克


    2.4 2.6 pipe read都是加锁的.混乱原因如上面分析.代码和标准中都得到确认.
不过你这确实引如一个新问题.在普通文件中的read可能出现的和write同步的问题.但问题只发生在并行执行write read
不能解释所有write执行完后 再read是否发生混乱

shujunz

感觉还是使用互斥锁方便

思一克

回复 81# epegasus


   
    2.4 2.6 pipe read都是加锁的.混乱原因如上面分析.代码和标准中都得到确认.
不过你这确实引如一个新问题.在普通文件中的read可能出现的和write同步的问题.但问题只发生在并行执行write read
不能解释所有write执行完后 再read是否发生混乱
---------
是的。
一个进程写，一个读，不会乱的。
2个以上在写，一个在读就乱了。因为读不考虑写锁i_mutex的状态的。
这个设计是合理的。因为多数时候是大量的进程同时读一个文件按（比如配置文件），而写的机会很少。
所以读不能在内核加锁头。如果有必要，用户自己加。

pipe的读写在块大小小于PIPE_BUF时候是无需锁的。绝对不会乱。这个有准确的说明，并且有很多精彩的程序就根据这个设计的。

epegasus

回复 83# 思一克


    先把什么叫"乱"讲清楚.以后就直接针对普通文件讨论
之前说的乱都是指2个写的交错执行. 导致"最终文件可读结果" 是2次或多次写结果的交错
定义一个交错就是一次write调用写入的2个部分被另一次write写入打断. 这里说的写入都是指对文件的最终结果产生影响,能由一次最终读看到.
当然首先就假设了这次最终读是不能被新的写入打断的.如果打断了将不会看到上面说的最终写的结果.这个与read加锁不加锁没关系.

再看read和write发生多进程操作的问题
首先一次read肯定读到的是他即将想要读的那部分的最终结果,这个最终结果至少存在于他开始读的那一时刻.而他读的时候至少有个原子区域是禁止修改的(按页的操作必定在使用一个页的时候锁定这个页)
当多个写发生时,而且都加了append方式.则read读的内容也是这多个写的最终结果,因为没有写会去修改别人写过的部分.也就是读永远发生在所有的写之后.而非append方式因为对于某个页,读可能发生在某个写前.而其他页则发生在这个写之后所以就导致读的的内容有2个最终可读结果的交错.这完全可理解为读写不同步-不能保证读总是在写后的原因导致的,本质上和多个write是否交错没什么关系

思一克

回复 84# epegasus


乱了就是：2个进程写同一文件同一位置，一个写全“0”， 一个写全“1”。
如果不乱，读到的结果要么是00000000,要么是11111111. 不可能是000111111或1111111000
乱了就出现混合了。