叉入临界段

Question

最近，在我接受的一次采访中，我们讨论了关键的部分。我们提出的问题是"what happens when we execute fork inside critical section? Will the resulting child process also execute the critical section simultaneously?“，我们讨论了各种可能性：

simultaneously

• fork()系统调用可能会阻塞子进程，只允许父进程执行关键section.

• Compiler可能足够智能以识别此问题，并可能引发编译错误。不幸的是，我在互联网上找不到更多关于这方面的细节。TIA.

编辑:添加伪代码以供参考：

semaphore s;
s.wait(); // lock
/* critical-section */
pid = fork(); /* what will happen here in child/parent process? */
s.signal(); // unlock

Answer 1

对于Linux信号量，sem_init的第二个参数确定它是否是跨进程信号量。您将这些存储放在共享内存中，这是由fork继承的。

fork不尝试检查现有的信号量，也不尝试调整信号量计数。信号量的计数可以大于1，并且允许许多正在运行的线程。因此，计数为2将允许两个线程运行- fork不会猜测。

编辑下面的旧答案假设是Linux，这更像是一个关键部分。

“批评”一节有误导性。在分叉之后，两个进程都有自己的关键部分。因此，您的三个选项都不适用。

Answer 2

，当我们在关键部分执行叉时会发生什么？生成的子进程也会同时执行关键部分吗？“

simultaneously

• fork()系统调用可能会阻塞子进程，只允许父进程执行关键section.

• Compiler可能足够智能以识别此问题，并可能引发编译错误。不幸的是，我在互联网上找不到更多关于这方面的细节。TIA.

这些和更多的原则上都是可能的，但我所知道的任何系统都不能实现(2)或(3)。特别是，由于你标记了Linux，GLibc的fork()没有任何关于与信号量交互的特殊规定，GCC不会以你建议的理由拒绝代码。(存在(System )信号量调整的问题，但这并不直接相关。

但(1)也不完全正确。确实，如果fork()成功，那么子程序将从分叉返回到关键部分，从而开始执行。在父部分仍然在关键部分本身中时，没有什么能具体地阻止这种情况发生，所以可能是两者同时在关键部分中运行。另一方面，两个产生的进程之一可能在另一个进程退出关键部分之后，才能真正执行任何指令。这看起来很像(2)，尽管从技术上讲，这两个进程都没有被阻塞。

然而，这仅仅是与这种情况有关的问题的冰山一角。