问一个关于fork后的文件操作的IO问题

MMMIX

楼主的问题不是出在记录锁问题，而是子进程互相做了其他进程地址空间的副本，
并且在for....for()中 ...
hohoss 发表于 2011-08-21 15:28

    他代碼的主要問題還就是把鎖用錯了。在那個寫循環中，lock type 只在第一次執行時設成了 F_WRLCK, 後面就都是 F_UNLCK 了，相當於沒有鎖。

skymoondyy

他代碼的主要問題還就是把鎖用錯了。在那個寫循環中，lock type 只在第一次執行時設成了 F_WRLCK ...
MMMIX 发表于 2011-08-21 23:38

    嗯，确实是锁没起作用，不过话说文件描述符都是继承下来的，都指向内核打开文件表中相同的文件，应该是共享文件偏移量的，（实际那句lseek都可以去掉）。所以加不加锁应该都不应该少字符才对，莫非是多核cpu的原因？

MMMIX

嗯，确实是锁没起作用，不过话说文件描述符都是继承下来的，都指向内核打开文件表中相同的文件， ...
skymoondyy 发表于 2011-08-23 11:16

    你这是假设 write 操作是原子的。若真是这样，这里的锁还真没必要。

atsjun

嗯，确实是锁没起作用，不过话说文件描述符都是继承下来的，都指向内核打开文件表中相同的文件， ...
skymoondyy 发表于 2011-08-23 11:16

lseek 还是需要的 虽然共享了文件大小
但是文件指针是相互独立的
不过确实不知道为什么会出现LZ的那个现象

MMMIX

lseek 还是需要的 虽然共享了文件大小

seek 是没有必要的。

不过确实不知道为什么会出现LZ的 ...
atsjun 发表于 2011-08-24 12:53

他把锁用错了，根本没锁上。

atsjun

他把锁用错了，根本没锁上。
MMMIX 发表于 2011-08-24 13:09

    是噢  没看见。。。

vincentff7

回复 10# hohoss


    fork虽然会暂时公用一些东西，但是有写时复制机制，本身就会避免两个进程间互相修改内容，怎么会出现这种互相改的情况了？我想fork系统调用应该会正确处理这种空间公用的状况吧？

MMMIX

回复  hohoss


    fork虽然会暂时公用一些东西，但是有写时复制机制，本身就会避免两个进程间互相修改 ...
vincentff7 发表于 2011-08-26 21:58

    Linux kernel 的 file table 在各個進程間是共享的，而 file offset 恰好在 file table 中，見 APUE Section 3.10 File Sharing

skymoondyy

seek 是没有必要的。



他把锁用错了，根本没锁上。
MMMIX 发表于 2011-08-24 13:09

   
seek没必要，因为父子进程共享文件的offset。write只写一个字节怎么也是原子操作了吧，所以按理锁也没有必要。所以我觉得这个问题，应该是多核处理器的问题。如果是单核，不会有这种问题。

MMMIX

seek没必要，因为父子进程共享文件的offset。write只写一个字节怎么也是原子操作了吧，所以按理锁也没有必要。所以我觉得这个问题，应该是多核处理器的问题。如果是单核，不会有这种问题。
skymoondyy 发表于 2011-08-29 09:48

    不要总是“觉得”、“按理”，测试一下嘛。