多线程 fork()

如何解决多线程 fork()

在多线程应用程序中，如果一个线程调用 fork()，它将仅复制该线程的状态。所以创建的子进程将是一个单线程进程。如果某个其他线程持有调用 fork() 的线程所需的锁，则该锁将永远不会在子进程中释放。这是个问题。 为了解决这个问题，我们可以通过两种方式修改 fork()。要么我们可以复制所有线程，而不仅仅是单个线程。或者我们可以确保（其他）非复制线程持有的任何锁都将被释放。那么在这两种情况下修改后的 fork() 系统调用是什么。这两者中的哪一个更好，或者这两种选择的优缺点是什么？

解决方法

这是一个棘手的问题。

POSIX 有 pthread_atfork() 来处理混合分叉和线程创建的混乱。该手册页的 NOTES 部分讨论了互斥锁等。但是，它承认正确使用它很困难。

该函数与其说是 fork() 的替代品，不如说是一种向 pthread 库解释您的程序需要如何准备以使用 fork() 的方式。

通常不会尝试从 fork 的子线程启动线程，而是退出该子线程或尽快调用 exec，将最大限度地减少问题。

这篇文章有一个good discussion of pthread_atfork()。

,

...或者我们可以确保（其他）非复制线程持有的任何锁都将被释放。

这将比您意识到的更难，因为程序可以完全在用户模式代码中实现“锁”，在这种情况下，操作系统将不知道它们。

即使你小心地只使用操作系统已知的锁，你仍然有一个更普遍的问题：创建一个只有一个线程的新进程有效与创建一个线程没有什么不同。使用所有线程创建新进程，然后立即杀死除其中一个之外的所有线程。

了解我们为什么不杀死线程。简而言之：锁不是唯一需要清理的状态。任何存在于父级但不存在于子级的线程，在 fork 调用的那一刻，可能正在制造需要清理的混乱。如果该线程在子进程中不存在，那么您已经失去了需要清理的知识。

---

我们可以复制所有线程而不是单个线程...

这也是一个潜在的问题。调用 fork() 的一个线程会知道调用 fork() 的时间和原因，并且它会准备进行 fork 调用。其他线程都不会有任何警告。而且，如果这些线程中的任何一个正在与进程外进行交互（例如，与远程服务对话），那么在您之前有一个客户端与该服务对话的地方，您突然有了两个客户端，与同一个服务交谈，他们都认为他们是唯一的一个。这不会有好的结局。

---

不要从多线程程序中调用 fork()。

在我参与的一个项目中：我们有一个大型多线程程序，需要生成其他进程。我们是如何做到的，我们让它在创建任何新线程之前生成一个简单的单线程“助手”程序。然后，每当它需要生成另一个进程时，它就会向帮助程序发送一条消息，而帮助程序就这样做了。