1. 導入
並行プログラミングは、システムのパフォーマンス向上や応答性改善に不可欠ですが、同時にデッドロックという厄介な問題を引き起こす可能性があります。デッドロックとは、複数のスレッドがお互いに相手が保持しているリソースの解放を待ち続け、結果としてシステム全体が永久に停止してしまう状態のことです。一度デッドロックが発生すると、プログラムは一切進まず、ユーザーは操作不能に陥ります。
HaskellのGHCランタイムには、このようなデッドロックを自動的に検知し、適切な例外を投げる強力な保護機能が組み込まれています。この機能のおかげで、バグによるデッドロックがシステムを完全にフリーズさせてしまうという最悪の事態を防ぎ、少なくとも問題発生を検知し、適切に対処する機会を得ることができます。本稿では、このGHCのデッドロック検知機能の仕組みと、実務でデッドロックに遭遇しないための対策について解説します。
2. 基礎知識
まずは、デッドロックとHaskellにおける並行処理の基本要素について理解しましょう。
デッドロックとは？
デッドロックは、以下の4つの条件がすべて満たされた場合に発生すると言われています（Coffmanの4条件）：
- 相互排他 (Mutual Exclusion): リソースは一度に1つのスレッドしか利用できない。
- 保持と待機 (Hold and Wait): リソースを保持しているスレッドが、別のリソースの解放を待つ。
- 非割込み (No Preemption): リソースは、それを保持しているスレッドによってのみ解放される。
- 循環待機 (Circular Wait): 複数のスレッドが、リソースを循環的に待ち合っている。
この状態になると、どのスレッドも処理を進めることができなくなり、プログラムが停止します。
HaskellにおけるMVarとデッドロック検知
Haskellの並行処理では、MVar（Mutable Variable）がスレッド間の同期と通信によく用いられます。MVarは、空か、または1つの値を保持している状態のどちらかを取る共有メモリセルです。
putMVar:MVarが空になるまで待機し、値を入れて満杯にする。takeMVar:MVarが満杯になるまで待機し、値を取り出して空にする。
もし、あるスレッドがtakeMVarをしようとしているMVarに、別のどのスレッドもputMVarする見込みがなくなった場合、そのスレッドは永遠に待機することになります。
GHCのランタイムは、このような「永遠に待機するしかないスレッド」を自動的に検知します。具体的には、ガベージコレクタ（GC）が到達不能なオブジェクトを回収する際に、同時に到達不能な（つまり、他のどのスレッドからも参照されず、かつ、MVarなどの同期プリミティブで永久にブロックされている）待機スレッドを発見すると、「BlockedIndefinitelyOnMVar」といった例外を発生させます。これは、循環待機によってプログラムがフリーズしている状態をGHCが教えてくれているサインなのです。
3. 実装/解決策
GHCのデッドロック検知機能を体験するために、意図的にデッドロックを発生させるプログラムを記述してみましょう。典型的なデッドロックのパターンとして、2つのスレッドが2つのMVarを異なる順序で取得しようとするシナリオを考えます。
シナリオ:
- スレッドA:
mvar1を取得 ->mvar2を取得 - スレッドB:
mvar2を取得 ->mvar1を取得
もしスレッドAがmvar1を、スレッドBがmvar2をそれぞれ同時に取得してしまった場合、お互いが相手のリソースを待ち続けることになり、デッドロックが発生します。
GHCは、このようにしてデッドロック状態に陥ったスレッド群を検知し、BlockedIndefinitelyOnMVar例外を投げます。これにより、プログラムがサイレントに停止するのではなく、エラーとして表面化し、開発者が問題に気づくことができるようになります。
4. サンプルプログラム
以下のHaskellプログラムは、前述のシナリオでデッドロックを発生させ、GHCがそれを検知する様子を示しています。
import Control.Concurrent
import Control.Concurrent.MVar
import System.IO (hPutStrLn, stderr)
main :: IO ()
main = do
— 2つのMVarを新しく作成します。最初はどちらも空の状態です。
mvar1 <- newEmptyMVar
mvar2 <- newEmptyMVar
hPutStrLn stderr "デッドロックを発生させるスレッドを開始します..."
-- スレッドAを起動
threadAId <- forkIO $ do
hPutStrLn stderr " [スレッドA] mvar1の取得を試みます..."
takeMVar mvar1 -- mvar1が空であればここでブロックされる
hPutStrLn stderr " [スレッドA] mvar1を取得しました。"
threadDelay 100000 -- デッドロックを発生させるために少し待機 (0.1秒)
hPutStrLn stderr " [スレッドA] mvar2の取得を試みます..."
takeMVar mvar2 -- mvar2が空であればここでブロックされる
hPutStrLn stderr " [スレッドA] mvar2を取得しました。"
hPutStrLn stderr " [スレッドA] 処理完了。"
putStrLn "スレッドAはデッドロックから抜け出しました。(このメッセージは通常表示されません)"
-- スレッドBを起動
threadBId <- forkIO $ do
hPutStrLn stderr " [スレッドB] mvar2の取得を試みます..."
takeMVar mvar2 -- mvar2が空であればここでブロックされる
hPutStrLn stderr " [スレッドB] mvar2を取得しました。"
threadDelay 100000 -- デッドロックを発生させるために少し待機 (0.1秒)
hPutStrLn stderr " [スレッドB] mvar1の取得を試みます..."
takeMVar mvar1 -- mvar1が空であればここでブロックされる
hPutStrLn stderr " [スレッドB] mvar1を取得しました。"
hPutStrLn stderr " [スレッドB] 処理完了。"
putStrLn "スレッドBはデッドロックから抜け出しました。(このメッセージは通常表示されません)"
-- 何も値をputMVarしていないため、スレッドAとBはどちらも永遠にMVarの取得を待ち続けます。
-- GHCのランタイムがこれを検知し、BlockedIndefinitelyOnMVar例外を投げます。
hPutStrLn stderr "メインスレッドは、デッドロック検知を待ちます..."
threadDelay 1000000 -- メインスレッドは1秒間待機し、デッドロック検知の機会を与える
hPutStrLn stderr "メインスレッドは終了しますが、デッドロックは検知されるはずです。"
実行結果の例:
このプログラムを実行すると、以下のような出力（エラーメッセージは環境やGHCバージョンにより多少異なる場合があります）が出て、最終的にデッドロックが検知されたことを示す例外が投げられます。
デッドロックを発生させるスレッドを開始します…
[スレッドA] mvar1の取得を試みます…
[スレッドB] mvar2の取得を試みます…
メインスレッドは、デッドロック検知を待ちます…
メインスレッドは終了しますが、デッドロックは検知されるはずです。
ご覧の通り、BlockedIndefinitelyOnMVar例外がスローされ、プログラムが異常終了しました。これにより、デッドロックが発生していることを明確に知ることができます。
5. 応用・注意点
GHCのデッドロック検知は非常に強力な機能ですが、これはあくまで「デッドロックの発生を知らせる」ものであり、「デッドロックを自動的に解決する」ものではありません。実務においては、デッドロックを未然に防ぐことが最も重要です。
デッドロック予防のためのヒント
- ロックの取得順序を統一する: 複数のリソースをロックする必要がある場合、すべてのスレッドで同じ順序でロックを取得するようにルールを徹底します。これにより、循環待機を防ぐことができます。
- ロックの粒度を小さくする: 必要最小限の期間、最小限のリソースのみをロックするようにします。ロックしている時間が長ければ長いほど、デッドロックの可能性は高まります。
- より高レベルな抽象化を利用する (STM): Haskellには、Software Transactional Memory (STM) という非常に強力な並行処理プリミティブがあります。
STMを使用すると、複数の共有状態への変更をアトミックなトランザクションとして扱うことができ、デッドロックやレースコンディションといった並行処理の問題を構造的に回避できます。複雑な並行処理では、MVarを直接操作するよりもSTMの利用を強く検討すべきです。 - タイムアウト処理を導入する:
Control.Concurrent.Async.timeout(asyncパッケージ) やControl.Concurrent.threadDelayといった機能を使って、特定のリソースの待機にタイムアウトを設定することも有効です。これにより、永久待機を避け、タイムアウトエラーとして処理を続行できます。
デッドロック検知の限界と注意点
- 検知のタイミング: GHCのデッドロック検知は、GCの実行タイミングに依存します。そのため、デッドロックが発生してから実際に例外が投げられるまでにタイムラグが生じる可能性があります。即座に検知されるわけではない点に注意が必要です。
- 例外ハンドリング: デッドロックが検知されて例外が投げられた場合、その例外を適切に捕捉し、システムを安全な状態に戻したり、再起動したりするロジックが必要です。
Control.Exception.catchなどを用いて例外ハンドリングを行いましょう。 - 全てのデッドロックを検知するわけではない: GHCのデッドロック検知は、主にHaskellランタイムが管理する同期プリミティブ（MVarなど）での無限ブロックを対象としています。外部システム（データベースのロック、OSレベルのミューテックスなど）に起因するデッドロックは検知できません。
HaskellとGHCは、並行処理を安全に記述するための多くのツールと保護機能を提供しています。デッドロック検知はその強力な一例であり、実務で並行プログラミングを行う際には、その存在を理解し、適切に活用するとともに、より堅牢な設計を目指すことが重要です。STMのような高レベルな抽象化を積極的に取り入れ、安全で信頼性の高いシステム構築を目指しましょう。
コメント