異常進程終止時的資源清理

Question

我的問題是，當一個進程異常終止時（通過信號，它可能是SIGKILL，所以我們不能攔截它），是否有任何保證的順序或原子性，其資源被釋放？ 特別是，我對文件鎖和共享內存感興趣。

例如：

1）如果進程持有2個文件的鎖並且異常終止，那么試圖鎖定相同文件的另一個進程是否可能看到一個文件被鎖定而另一個文件被解鎖？ 或者從其他進程的角度來看，釋放文件鎖原子的過程是什么？

如果它不是原子的，那么是否存在至少一個預定義的順序，其中文件鎖將由終止進程釋放（例如，它們最初被鎖定的順序相反）？

2）我想使用文件鎖來確保正確的共享內存初始化 - 映射到共享內存的進程將保持共享鎖，並且想要映射到同一共享內存段的新進程將嘗試測試該鎖以查看是否需要執行初始化（如果需要，我可以在以后提供更多詳細信息）。

但是同樣的問題出現在這里：如果一個持有文件鎖並且也映射到共享內存段的進程異常終止，那么在共享內存自動取消映射后，另一個進程是否仍然會看到文件鎖被鎖定？ 或者是從其他進程的角度取消映射共享內存段並解鎖文件原子？

Answer 1

正如您的問題所暗示的，這取決於發送到程序的終止信號。 AFIK它真的只有KILL（即kill -kill ）會終止一個進程，而不會給進程一個正確關閉自己的機會。 其他信號如TERM OR SIGINT 可以被程序本身掛鈎並被忽略，或者用於啟動一些干凈的關閉過程。 我想像SIGHUP這樣最溫和的信號不會做任何事情，除非代碼中有明確的鈎子編程。 所以我不知道你關於文件鎖的問題的具體答案，但考慮一下這個事實，你可能只是真的kill -kill了 - 你在這里擔心。

Answer 2

不，發布資源沒有順序。 只有當然，鎖定在進程終止后釋放。

據我了解你的問題，你持有兩個或更多相互關聯的“鎖”。 不知何故，您的應用程序取決於鎖的確切釋放順序。 在不了解您的問題的詳細信息的情況下，這似乎只是糟糕的設計 。

如果文件的鎖定取決於共享內存的鎖定，則應以編程方式實現此依賴項。

另一個解決方案是等待例如100毫秒，檢查第二個鎖。 因為您可以假設，終止進程的所有鎖定都將在短時間內釋放。 如果您新啟動的應用程序可以獲得第一個鎖，它將首先等待100毫秒，然后再嘗試獲取文件鎖（反之亦然）。 如果此時僅終止進程，則會自動避免任何競爭條件 。