异常进程终止的资源清理
我的问题是，当一个进程异常终止时(通过一个信号，它可能是SIGKILL，所以我们无法拦截它)，是否存在释放其资源的任何保证顺序或原子性？特别是，我对文件锁和共享内存感兴趣。
例如：
1)如果进程对两个文件持有锁并异常终止，那么另一个试图锁定相同文件的进程是否会看到一个文件被锁定，另一个文件被解锁？或者从其他进程的角度来看，释放文件锁的过程是原子的吗？
如果它不是原子的，那么是否至少有一个预先定义的顺序，文件锁将由终止过程释放(例如，它们最初被锁定的顺序相反)？
2)我希望使用文件锁来确保正确的共享内存初始化--映射到共享内存中的进程将持有共享锁，而希望映射到同一个共享内存段的新进程将尝试测试该锁，以查看是否需要执行初始化(如果需要，我可以稍后提供更多细节)。
然而，这里也会出现同样的问题:如果持有文件锁并同时映射到共享内存段的进程异常终止，那么在共享内存自动取消映射之后，另一个进程是否仍会将文件锁视为锁定？或者，从其他进程的角度来看，共享内存段的取消映射和文件解锁是原子性的吗？
回答 2
Stack Overflow用户
发布于 2013-11-09 01:05:23
正如你的问题所暗示的，这取决于发送到程序的杀死信号。它实际上只会终止一个进程(即kill -kill)，而不会给进程一个适当关闭自己的机会。其他信号，如术语或SIGINT，可以由程序本身钩住，或者被忽略，或者用来启动一些干净的关闭过程。我猜 --像SIGHUP这样的最温和的信号--不会做任何事情，除非代码中有显式的钩子。因此，我不知道您关于文件锁问题的具体答案，但请考虑这样一个事实:您在这里担心的可能只是kill -kill。
Stack Overflow用户
发布于 2014-03-03 09:39:04
不，没有释放资源的命令。只有在进程终止之后，才会释放锁。
我理解你的问题，你持有两个或两个以上的“锁”，它们相互关联。不知何故，您的应用程序依赖于锁的确切发布顺序。在不了解您的问题的细节的情况下，这似乎只是糟糕的设计。
如果文件的锁取决于共享内存的锁，则应以编程方式实现此依赖关系。
另一个解决方案是等待100毫秒，检查第二个锁。因为您可以假设，终止进程的所有锁都将在短时间内释放。如果您的新启动的应用程序可以获得第一个锁，它将首先等待100毫秒，然后尝试获取文件锁(或者相反)。这个自动的避免了在此时进程被终止的任何竞争条件。
https://stackoverflow.com/questions/19674214
复制相似问题
腾讯云开发者
