我的问题是，当一个进程异常终止时（通过一个信号，它可能是SIGKILL所以我们无法拦截它），是否有任何保证的顺序或原子性来释放其资源？特别是，我对文件锁和共享内存感兴趣。
例如：
1）如果进程持有2个文件的锁并且异常终止，那么试图锁定相同文件的另一个进程是否可能看到一个文件被锁定而另一个文件被解锁？或者从其他进程的角度来看，发布文件锁原子的过程是什么？
如果它不是原子的，是否至少有一个预定义的顺序，终止进程将释放文件锁（例如，它们最初被锁定的顺序相反）？
2）我想使用文件锁来确保正确的共享内存初始化 - 映射到共享内存的进程将保存共享锁，并且想要映射到同一共享内存段的新进程将尝试测试该锁查看是否需要执行初始化（如果需要，我可以在以后提供更多详细信息）。
然而，同样的问题出现在这里：如果一个持有文件锁并且也映射到共享内存段的进程异常终止，是否有可能在共享内存自动取消映射后，另一个进程仍然会看到文件锁被锁定？或者是从其他进程的角度取消映射共享内存段并解锁文件原子？
答案 0 :(得分：0)
正如您的问题所暗示的，这取决于发送到程序的终止信号。 AFIK它实际上只有KILL（即kill -kill）才能终止进程，而不会给进程提供正确关闭自己的机会。其他信号如TERM OR SIGINT 可以被程序本身挂钩并被忽略，或者用于启动一些干净的关闭过程。 I guess像SIGHUP这样最温和的信号将不会做任何事情，除非代码中有明确的钩子编程。所以我不知道你关于文件锁的问题的具体答案，但考虑一下你可能只在这里担心的kill -kill这个事实。
答案 1 :(得分：0)
不，发布资源没有顺序。只有当然，锁定在>过程终止后被释放。
据我所知，你持有两个或两个以上相互关联的“锁”。不知何故，您的应用程序取决于锁的确切释放顺序。在不了解您的问题的详细信息的情况下，这似乎只是糟糕的设计。
如果文件的锁定取决于共享内存的锁定，则应该以编程方式实现此依赖项。
另一种解决方案就是等待，例如100毫秒，检查第二个锁。因为您可以假设，终止进程的所有锁定都将在短时间内释放。如果您新启动的应用程序可以获得第一个锁，它将首先等待100毫秒，然后再尝试获取文件锁（反之亦然）。如果此时正在终止进程，则会自动避免任何竞争条件。