multithreading - 混合线程、 fork 和互斥锁，我应该注意什么？

Question

如果我 fork一个线程持有互斥锁的过程，如果我立即exec我相对安全吗？在 child ？在我之前 child 做什么事情是安全的exec ?

如果执行 fork 的线程然后 child 在调用 exec 之前继续释放互斥锁这会导致问题吗？如果我尝试在父进程之前拥有的子进程中获取互斥锁会发生什么 fork (并且可能仍然拥有或可能不拥有)？

不同平台的答案是否不同？我主要关注 Unix 变体，尤其是 Linux。但是我对NT很好奇。当然，NT 没有(据我所知)fork .

Answer 1

见 pthread_atfork ，尤其是 RATIONALE 部分，用于讨论与 fork 相关的问题在多线程环境中。它还提示了在 fork 之前和之后应该有效的内容。在 child 和 parent 之间。

更新:RATIONALE 部分是非规范的，结果与标准的其他部分发生冲突。见 this defect report由戴夫·布滕霍夫 (Dave Butenhof) 提供更多详细信息。

立即exec之后 fork应该对多线程程序的任何状态(即，持有任何互斥锁的任何线程)都是安全的。至于fork之间可能的事情和 exec ，情况复杂:

最重要的是，子进程中只有一个线程(称为 fork 的线程)被复制。因此，在 fork 时刻由另一个线程持有的任何互斥锁永远被锁定。也就是说(假设非进程共享互斥体)它在子进程中的副本被永远锁定，因为没有线程可以解锁它。

在 fork 之后释放互斥锁在可能的情况下是安全的，也就是说，如果 fork ing 线程首先拥有互斥锁。就是这样pthread_atfork处理程序通常有效:在 fork 之前锁定互斥锁，在子级解锁和在父级解锁。

至于获取进程在 fork 之前拥有的互斥锁(请记住，我们讨论了子地址空间中的副本):如果它由 fork 拥有ing 线程，它是递归锁定(适用于 PTHREAD_MUTEX_RECURSIVE)；如果它被另一个线程拥有，它将永远保持锁定状态并且无法重新获取。

通过注册合适的 pthread_atfork处理程序，第三方库可以提供在fork之间安全使用的保证。和 exec . (我希望它主要来自编程语言运行时，而不是通用库)。

经过更多研究，我建议避免以任何方式依赖 pthread_atfork ，除了 fork 之间的异步信号安全调用之外什么都不做和 exec (放弃 fork/exec 换 posix_spawn 会更好)。

问题是，fork本身可以在信号处理程序中调用。它排除了对 pthread_atfork 的任何非平凡使用，即使它的基本原理明确提到在子进程中解锁互斥体和重新创建线程(!)。

我认为存在不同可能解释的“灰色地带”仍然存在:

对于 pthread_atfork已知从不调用 fork 的程序中的处理程序在信号处理程序中。

对于在 fork 周围发生的非 pthread-atfork 操作不在信号处理程序中的调用。

但是对于可移植应用程序使用哪种读数是非常清楚的。