8

私の質問は、プロセスが異常終了した場合 (シグナルを介して SIGKILL である可能性があるため、傍受できない)、そのリソースが解放される順序または原子性が保証されているかどうかです。特に、ファイル ロックと共有メモリに関心があります。

例えば：

1) プロセスが 2 つのファイルのロックを保持していて、異常終了した場合、同じファイルをロックしようとしている別のプロセスが、1 つのファイルがロックされ、別のファイルがロック解除されているのを見る可能性はありますか? それとも、他のプロセスの観点から、ファイル ロックの解放プロセスはアトミックですか?

アトミックでない場合、少なくとも、終了プロセスによってファイル ロックが解放される事前定義された順序はありますか (たとえば、最初にロックされた順序とは逆の順序で)?

2) 適切な共有メモリの初期化を確実にするためにファイル ロックを使用したかった - 共有メモリにマップされたプロセスは共有ロックを保持し、同じ共有メモリ セグメントにマップしたい新しいプロセスはそのロックをテストして、初期化を実行する必要があります (必要に応じて後で詳細を説明できます)。

ただし、ここで同じ疑問が生じます。ファイル ロックを保持し、共有メモリ セグメントにもマップされているプロセスが異常終了した場合、共有メモリが自動的にマップ解除された後も、別のプロセスがファイル ロックをロックされていると見なす可能性はありますか? それとも、共有メモリセグメントのマッピング解除とファイルのロック解除は、他のプロセスの観点からアトミックですか?

4

2 に答える 2

0

あなたの質問が暗示しているように、これはプログラムに送信される kill シグナルに依存します。AFIKは、実際にはKILL（つまりkill -kill）だけで、プロセスに適切にシャットダウンする機会を与えずにプロセスを終了します。TERM OR SIGINT などの他のシグナルは、プログラム自体によってフックされ、無視されるか、クリーン シャットダウン プロセスを開始するために使用されます。コードに明示的なフックがプログラムされていない限り、SIGHUP のような最も穏やかなシグナルは何もしないと思います。そのため、ファイル ロックに関するご質問に対する具体的な回答はわかりませんが、おそらくkill -killあなたがここで心配しているのは、おそらくそれだけであるという事実を考慮してください。

于 2013-11-09T01:05:23.053 に答える
0

いいえ、リソースの解放に順序はありません。確かに、ロックはプロセスが終了した後に解放されます。

あなたの質問を理解しているように、あなたは互いに関連する 2 つ以上の「ロック」を保持しています。どういうわけか、アプリケーションはロックの正確な解放順序に依存しています。あなたの問題の詳細を知らなければ、これは単なる悪い設計のようです。

ファイルのロックが共有メモリのロックに依存している場合は、この依存関係をプログラムで実装する必要があります。

別の解決策は、たとえば 100 ミリ秒待機して、2 番目のロックを確認することです。想定できるため、終了したプロセスのすべてのロックは短時間で解放されます。新しく起動したアプリケーションが最初のロックを取得できる場合、最初に 100 ミリ秒待機してから、ファイル ロックを取得しようとします (逆の場合)。これにより、プロセスがこの時点で終了した場合、競合状態が自動的に回避されます。

于 2014-03-03T09:39:04.157 に答える