linux 琐碎知识点

http://blog.codingnow.com/2011/01/fork_multi_thread.html

• 在 POSIX 标准中，fork 的行为是这样的：复制整个用户空间的数据（通常使用 copy-on-write 的策略，所以可以实现的速度很快）以及所有系统对象，然后仅复制当前线程到子进程。这里：所有父进程中别的线程，到了子进程中都是突然蒸发掉的。

其它线程的突然消失，是一切问题的根源。

可能产生的最严重的问题是锁的问题。

因为为了性能，大部分系统的锁是实现在用户空间的。所以锁对象会因为 fork 复制到子进程中。

对于锁来说，从 OS 看，每个锁有一个所有者，即最后一次 lock 它的线程。

假设这么一个环境，在 fork 之前，有一个子线程 lock 了某个锁，获得了对锁的所有权。fork 以后，在子进程中，所有的额外线程都人间蒸发了。而锁却被正常复制了，在子进程看来，这个锁没有主人，所以没有任何人可以对它解锁。

当子进程想 lock 这个锁时，不再有任何手段可以解开了。程序发生死锁。

为何，POSIX 指定标准时，会定下这么一个显然不靠谱的规则？允许复制一个完全死掉的锁？答案是历史和性能。因为历史上，把锁实现在用户态是最方便的（今天依旧如此）。 背后可能只需要一条原子操作指令即可。大多数 CPU 都支持的。fork 只管用户空间的复制，不会涉及其中的对象细节。

一般的惯例，多线程程序 fork 前，应该由发起 fork 的线程 lock 所有子进程可能用到的锁，fork 后，把它们一一 unlock 。当然，这样的做法就隐含了锁的次序。如果次序和平时不同，那么就会死锁。

不光是显式的使用锁，许多 CRT 函数也会间接的使用。比如 fprintf 这些文件操作。因为对 FILE * 的操作是依靠锁来达到线程安全的。最常见的问题是在子线程里调用 fprintf 写 log 。

• 在多线程程序里使用fork是比较郁闷的事情；

不只是应用层的锁的问题；
很多C库里的函数调用也会出现死锁线程；
最好的办法是在多线程进程里不是用fork；
如果非使用不可，尽量fork完毕后直接exec，不调用任何其他除了fork之外的函数；
exec可以覆盖内存空间，可以解决所有关于锁的问题；

• 先fork()后再用pthread，唯一的可移植用法。