处理MPI应用程序中的信号/正常退出

Question

如何处理信号和MPI应用程序（例如SIGUSR1，它应该告诉应用程序它的运行时已经过期并且应该在接下来的10分钟内终止。） 我有几个限制因素：

• 首先完成所有并行/串行IO，然后退出应用程序！
• 在所有其他情况下，应用程序可以毫无问题地退出

如何安全地实现这一点，在尝试退出时没有死锁，并且正确地将当前上下文跳回main()并调用MPI_FINALIZE()？ 不知何故，进程必须对退出进行协商（我认为这在多线程应用程序中是相同的）但是如何有效地完成而无需进行多少通信？是否有人知道这种做法的一些标准方法？

以下是一些可能会或可能不会起作用的想法：

创意1：
让我们说，对于每个进程，我们在信号处理程序中捕获信号并将其推送到“未处理的信号堆栈”（USS），我们只需从信号处理程序例程返回。然后，我们在应用程序中有特定的终止点，特别是在IO操作之前和之后，然后处理USS中的所有信号。 例如，如果USS中存在SIGUSR1，则每个进程将在终止点退出。

• 这个想法存在一个问题，即仍然可能存在死锁，进程1只是捕获一个终端点，而进程2已经通过了这一点，现在正在启动并行IO。进程1将退出，这将导致进程2中的死锁（等待IO退出的进程1）...

创意2：
只有主进程0捕获信号处理程序中的信号，然后发送广播消息：“所有进程退出！”在应用程序的特定点。所有进程都会收到广播，并且会在main中捕获并抛出异常，并调用MPI_FINALIZE。

• 通过这种方式退出安全，但是必须接收连续广播消息以查看是否应该退出

非常感谢！

Answer 1

如果您的目标是在同一点停止所有进程，则无法始终在可能的终止点进行同步。也就是说，需要在终止点进行集体呼叫。

当然，您可以尝试通过使用另一个集体呼叫的同步来避免额外的广播，以确保正确终止，或者在现有广播上捎带终止信息，但我认为这不值得。毕竟，您只需要在I / O之前进行同步，并且每十分钟至少进行一次同步。在这样的频率下，即使广播也不是性能问题。

Answer 2

通常在MPI应用程序中使用信号是不安全的。某些实现可能会支持它，而其他实现可能不支持。

例如，在MPICH中，进程管理器使用SIGUSR1进行异常故障的内部通知。

http://lists.mpich.org/pipermail/discuss/2014-October/003242.html

另一方打开MPI会将SIGUSR1和SIGUSR2从mpiexec转发到其他流程。

http://www.open-mpi.org/doc/v1.6/man1/mpirun.1.php#sect14

其他实施方式会有所不同。因此，在您走这条路线太远之前，请确保您正在使用的实施可以处理它。