诡异的多核问题

books_soul

假设一个文件file1内容为：
ab
a
cc


此时分别在单核机器和SMP机器下执行下面这条命令:
cat file1 | grep -v "cc" > file1

结果是，在单核下，file1的内容将是：
ab
a
在SMP情况下，file1的内容将是：
空的。

哪位能具体给讲讲为啥会出现两种不同的结果？会是kernel引起的么？

tempname2

大概，大概，大概，大概：

单核时，cat 与 grep 串行运行，grep是得的到输入的。

多核时，cat 与 grep 并行运行，如果grep先运行的话,file1的内容就会被清空，cat的输出就为空了。

myguyan

大概，大概，大概，大概：

单核时，cat 与 grep 串行运行，grep是得的到输入的。

多核时，cat 与 gre ...
tempname2 发表于 2010-09-11 18:44

不能这么说，如果这样解释，那多核和SMP还有意义吗？

问题确实比较诡异，我也没想明白

kouu

回复 3# myguyan


    为什么说这样子多核就没有意义了呢？

    两个“同时”运行的进程，一个要读文件、另一个要清空文件，并且两者之间没有任何同步措施。最后到底文件是先被读还是先被清空，这个是没有保证的。

smalloc

回复 4# kouu


    如果在多核下不能保证.那么在单核下可内核抢占时也没有保证了

kouu

为什么要保证呢？ 两个进程，各干各的事，有要求内核提供什么保证吗？ 没有吧…… 那么还保证什么？

Godbach

cat file1 | grep -v "cc" > file1

把这条命令改成：

cat file1 | grep -v "cc" > file2

再试试。

smalloc

回复 6# kouu


    我是说如果多核不能保证.那么单核也不能保证.
既然这样.那么于核无关.就是在任何情况下,2个程序的先后无保证.
那我们还敢用SHELL做什么呢?
这个代码用了管道.
想下fork grep后程序后必是先把输入输出描述符准备好.然后在while处理一直到输入没有为止或者被关闭为止.处理的就往输出里写.
如果先后无保证,即你说的2个程序并行.可能一开始就不能初始化好输入.因为可能CAT 还没准备好输出描述符号.
所以在fork grep前至少保证了cat进程已经将file打开了. 这个过程应该有shell实现来保证.

kouu

所以在fork grep前至少保证了cat进程已经将file打开了. 这个过程应该有shell实现来保证.
smalloc 发表于 2010-09-13 18:33

我和你的想法不一样。我的理解是，shell只管fork两个进程，利用管道重定向它们的fd，然后分别execve执行"cat file1"和"grep -v "cc" > file1"。
在第一个execve里面，file1只是cat这个应用程序的参数，shell怎么知道它什么时候open(file1)？ shell根本就不知道cat程序要把file1参数当作文件来打开。那么shell又怎么保证fork grep前cat进程已经将file打开了？shell要做的事情只是运行cat，并把file1作为参数传到cat的main函数里面。要不要open(file1)，那是cat的事情。

至于grep -v "cc" > file1，这里可能有些纠结。我之前的理解是：shell可能会在fork出执行grep的进程之前就把file1打开了，并重定向grep的输出。如果是这样的话，在cat和grep开始之前，file1就已经被清空了。
但是在我和环境里面，shell的执行流程是：（用strace观察的）
1、pipe创建管道
2、clone两个子进程（两个子shell），并使用管道做重定向
3、两个子shell分别去执行cat file1和grep -v "cc" > file1
这样的话，cat file1执行的时候，file1的确有可能还有被执行grep的那个子shell打开的。

kouu

仔细想了一下，好像明白 smalloc  兄的意思了。
“所以在fork grep前至少保证了cat进程已经将file打开了“，smalloc兄的理解是不是：
1、shell应该顺序执行管道符相连的程序；
2、当前一个程序有输出以后，才会fork第二个进程，以执行第二个程序；

我的理解不是这样的，我认为shell是一下子就fork两个子进程，然后分别执行两个程序。具体第一个程序什么时候write、第二个程序什么时候read，shell不管。
执行sleep 100 | echo 123试一试，123会立马输出，而不是等到100秒以后。