论坛徽章:: 0

电梯直达

1楼 [收藏(0)] [报告]

发表于 2008-11-24 15:15 |只看该作者 |倒序浏览

本来发在LINUX内核版的，借借这里的人气。

这是我在一个论坛上偶然看到的，在讨论中有人提出LINUX系统中的fork()函数行为不够清晰。
比如在一个多线程的其中一个线程中执行fork()函数，是应该复制整个进程（即所有线程）还是仅仅复制当前调用fork()的线程。当然他对
LINUX不够熟悉。但是他提出了一个很有意思的例子来说明fork()的不足。
这里先把几个概念理一下：
多线程：由于LINUX并没有显式支持进程和线程的区别，使用了所谓的轻量级进程表示线程，所以这里的多线程表示的是共享虚拟地址空间（和信号处理所需的数据结构以及诸如文件等等，不过这里共享虚拟地址空间所引起的问题最大）。也就是通常使用fork()函数时指定CLONE_VM以及相关的flag，或者使用clone()，或者使用pthread库创建的进程。这些所有的调用最后都是使用do_fork()，外加flag的特定限制，特别的使用CLONE_VM指定新进程（线程）使用当前进程的虚拟地址空间，包括页目录和页表。
也就是说，这些多线程共用一个虚拟地址空间，包括页表和页目录。问题也就开始出现了。

现在举一个例子：假如一个SMP系统上面有若干个多线程，t1,t2,...tn，它们使用两个全局变量glob1, glob2进行某方面的同步，需要使用诸如信号量之类的锁进行互斥控制。在绝大多数情况下，都是没有问题的。现在假设线程t1执行了fork()希望创建一个进程（而不是线程，即新创建的子进程尽管初始的虚拟地址空间跟父进程完全一样，但是使用了COW技术保证它们有自己独立的虚拟地址空间）。在现在的内核中，do_fork()调用具体函数将父进程的mm_struct以及vma链表复制给子进程，同时也将父进程的页目录和页表复制给子进程的页目录和页表。但是由于内核无法完全控制父进程的页目录和页表（尽管它拥有控制互斥的自旋锁和信号量，其他CPU上内核执行路径是已经无法修改访问父进程的mm和页表，页目录。但是其他CPU上在用户态运行的线程t2,t3,..tn都可以访问页目录和页表。
假设这个多线程中有这样一个临界区代码：

  ...........
  mutex_lock()
glob1 += 2;
glob2 -= 2;
mutex_unlock();
...........
也就是说glob1和glob2要吗都不改变，要吗都需要改变，也就是原子操作。
假设glob1和glob2属于同一个页（那么也属于同一个物理页）。当内核在执行t1的do_fork时，对于glob1和glob2所在的物理页作COW，具体一点就是把指向该物理页的pte设为只读。如果其他CPU上某个线程ti正在临界区，那么就有可能出现以下执行序列：

  ti： mutex_lock();
      glob1 += 2;
               t1: 内核将指向该物理页的pte置为只读（COW）
  ti: glob2 -= 2;  //在这里，由于现在的pte是只读的，会发生缺页异常，COW将使得glob2的修改只对t1,t2,...tn可见，
               //而子进程中的glob2没有被修改
   mutex_unlock();

在刚创建的子进程返回到用户态时，它的glob1和glob2处在不一致状态？！

文库|博客

yhb04

稍有积蓄

论坛徽章:: 0

2楼 [报告]

发表于 2008-11-24 17:56 |只看该作者

我来说说我自己的观点：
在现在的LINUX内核中这个问题确实存在，并且很难改变。
引起这个问题的本质原因是：内核无法完全控制其他CPU上的线程在用户态对页目录和页表的访问控制。
如果是单线程，就不会出现这种问题。
我所能想到的解决方法：
1.最为暴力的，内核在执行do_fork()时把内存锁住。
  这个方法不可行，首先这会完全限制SMP中其他CPU对内存的访问，由于do_fork()的执行时间比较长，会有很大的开销。
  其次，就算锁住内存也无济于事，因为在锁住内存之前，其他线程还是有可能处在临界区，跟不锁内存的情形大致一样。
2.fork()仍然只复制当前线程，但是在复制之前，通过一定的机制让所有的其他线程暂时停止执行。
  这里有个问题，如果其他线程在临界区内被停止执行，仍然会有不一致问题。所以必须考虑让所有线程在临界区外被暂时
  停止，但是这个似乎很难实现。
3.改变fork()的语义，让fork()复制所有的线程，如果确实能够实现，那么可以解决不一致问题。但是这需要修改内核，而且
  do_fork()的实现会变得非常复杂。

或者仅仅把上面的不一致问题看成是用户自己的责任，就像用户自己malloc()后不free()导致内存泄露一样。
1.如果在多线程中fork()一个跟自己共享虚拟地址空间的线程（而非进程），那么不会有不一致。
2.如果在单线程中fork()一个进程，也不会出现不一致。
3.如果在多线程中fork()一个进程，但是这个新进程马上使用execve()，也不会有问题。

只有在以下情形中会出现问题
4.如果在多线程中fork()一个进程，但是不使用execve()之类的函数，那么该新进程中的全局变量就可能出现不一致。