Why did HeapFree fail with ERROR_POSSIBLE_DEADLOCK? - The Old New Thing - Site Home - MSDN Blogs
ある顧客がassertに引っかかると報告してきた。何でも、HeapFree関数が、全く問題ないヒープブロックに対する操作に失敗し、GetLastError関数の結果は、ERROR_POSSIBLE_DEADLOCKだという。一体何がどうなっているのだ。
私の同僚が持ち前のエスパー能力を駆使して訊ねた。「ひょっとしてプロセスは終了中かい?」
「ええ、まあ。何で分かったんだい?」
プロセスはどのように終了するかという話を思い出して欲しい。まず最初に起こることは、プロセスの他のスレッドをすべて、強制的に終了させるのである。これにより、スレッドによって所有されていた同期リソースがロックされたままになる可能性がある。この場合、同期リソースとはヒープである。
ある関数がHeapFreeを呼んだ際、ヒープのコードはヒープをロックしようとするが、他のスレッドによって所有されているので、ロックできないことを検知する。そして、その他のスレッドはすでに終了しているのだ(他のスレッドはHeapFreeの操作の最中に強制終了される可能性がある)。ヒープのコードはこの状況を検知し、デッドロックを回避して、ERROR_POSSIBLE_DEADLOCKを返す。
これと同様に、プロセスの終了中に、メモリーを安全に確保することはできない。つまり、メモリーは確保も解放もできないのだ。前回学んだように、プロセスが終了中であるならば、クリーンアップなどすべきではないのだ。プロセスのアドレス空間が解放されるときに、メモリーはすべて解放される。手動で解放する必要はない。時間の無駄である。
Windowsにおいて、プロセスの終了中にリソースを解放する必要はない。この単純なルールを理解出来ないWindowsプログラマーは実に多い。そういうプログラマーの書いたコードは、プログラムの終了時にまぬけにも例外エラーを出したりする。
No comments:
Post a Comment
You can use some HTML elements, such as <b>, <i>, <a>, also, some characters need to be entity referenced such as <, > and & Your comment may need to be confirmed by blog author. Your comment will be published under GFDL 1.3 or later license with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.