分散システム、本当に「正しく」開発できますか？ #JTF2018 / July Tech Festa 2018

July Tech Festa 2018 で使用したスライドです。二相コミットを例として、分散アルゴリズムの検証にモデル検査を使用する手法について解説しています。また、代表的なモデル検査ツールである SPIN、TLA+、P について、同じシステムを各ツールで記述してみることでその特定の違いについて学びます。

イベント概要：https://2018.techfesta.jp/speakers#C40
ブログ記事：http://ccvanishing.hateblo.jp/entry/2018/08/01/055608

Transcript

1. 分散システム、　 本当に「正しく」 開発できますか？ チェシャ猫 (@y_taka_23) July Tech Festa 2018 (2018/07/29)
2. #JTF2018 by @y_taka_23
3. 目次 • 数理的手法による検証とは ◦ 特にモデル検査の長所と短所 • 検証のための理論と枠組み ◦ システムの挙動をどうやって表現するのか ◦ 検査したい仕様をどうやって表現するのか • 検証ツール各種の記述方法の比較 ◦ SPIN、TLA+、P それぞれの特徴
4. 数理的手法の世界 1
5. 分散システムはテストしづらい • 各プロセスが非同期的に動く ◦ 考えるべきパターンが多すぎる • プロセス間で通信が発生 ◦ パケットの遅延・消失・破損が起こりうる • 仕様そのものが複雑になりがち ◦ 瞬間ではなく、一連の挙動が問題になる ◦ もし仕様バグがあっても発見しづらい
6. 人間の直感だけではまともに戦えない世界
7. 形式手法 Formal Methods
8. 形式手法の分類 • 定理証明 ◦ 数学的な証明を人の手でプログラムとして表現 ◦ 代表的なツール : Coq、Agda、Isabelle • モデル検査 ◦ システムが取りうる状態を総当たり探索 ◦ 有限のパターンしか保証できないが自動化できる ◦ 代表的なツール : SPIN、TLA+、P、Alloy
9. 例：リストの反転
10. Fixpoint rev (xs : list bool) : list bool := match xs with | nil => nil | x :: xs’ => rev xs’ ++ (x :: nil) end. 実装とテストしたい仕様
11. Fixpoint rev (xs : list bool) : list bool := match xs with | nil => nil | x :: xs’ => rev xs’ ++ (x :: nil) end. (* rev (rev xs) = xs ? *) 実装とテストしたい仕様
12. Fixpoint rev (xs : list bool) : list bool := match xs with | nil => nil | x :: xs’ => rev xs’ ++ (x :: nil) end. (* rev (rev xs) = xs ? *) rev (rev []) = [] rev (rev [true]) = [true] rev (rev [true; false]) = [true; false] rev (rev [true; true; false]) = [true; true; false] ... 実装とテストしたい仕様
13. 定理証明の考え方
14. Theorem rev_involutive : forall xs : list bool, rev (rev xs) = xs. Proof. Qed. 数学的帰納法による証明
15. Theorem rev_involutive : forall xs : list bool, rev (rev xs) = xs. Proof. intro. induction xs [| x xs’ xs’_is_ok]. simpl. apply eq_refl. Qed. 数学的帰納法による証明 xs = nil の場合、 直接計算すれば = が成り立つ
16. Theorem rev_involutive : forall xs : list bool, rev (rev xs) = xs. Proof. intro. induction xs [| x xs’ xs’_is_ok]. simpl. apply eq_refl. simpl. rewrite rev_app_distr. simpl. rewrite xs’_is_ok. apply eq_refl. Qed. 数学的帰納法による証明 xs = x :: xs’ の場合、 xs’ では = が成り立つとして 式変形を行う
17. モデル検査の考え方
18. 長さ 3 以下の範囲で自動全探索
19. [] [true] [false] [true; true] [true; false] [false; true] [false; false] [true; true; true] [true; true; false] [true; false; true] [false; true; true] [true; false; false] [false; true; false] [false; false; true] [false; false; false] 長さ 3 以下の範囲で自動全探索
20. rev (rev []) rev (rev [true]) rev (rev [false]) rev (rev [true; true]) rev (rev [true; false]) rev (rev [false; true]) rev (rev [false; false]) rev (rev [true; true; true]) rev (rev [true; true; false]) rev (rev [true; false; true]) rev (rev [false; true; true]) rev (rev [true; false; false]) rev (rev [false; true; false]) rev (rev [false; false; true]) rev (rev [false; false; false]) 長さ 3 以下の範囲で自動全探索
21. rev (rev []) = [] rev (rev [true]) = [true] rev (rev [false]) = [false] rev (rev [true; true]) = [true; true] rev (rev [true; false]) = [true; false] rev (rev [false; true]) = [false; true] rev (rev [false; false]) = [false; false] rev (rev [true; true; true]) = [true; true; true] rev (rev [true; true; false]) = [true; true; false] rev (rev [true; false; true]) = [true; false; true] rev (rev [false; true; true]) = [false; true; true] rev (rev [true; false; false]) = [true; false; false] rev (rev [false; true; false]) = [false; true; false] rev (rev [false; false; true]) = [false; false; true] rev (rev [false; false; false]) = [false; false; false] 長さ 3 以下の範囲で自動全探索
22. (たぶん）rev (rev xs) = xs 長さ 3 以下の範囲で自動全探索
23. 第 1 章のまとめ • 分散システムには特有の難しさがある ◦ 考えるべきパターンが多く、再現性がない • 形式手法による検証は大きく分けて二種類 ◦ 定理証明：手動・無限のパターンに対して保証 ◦ モデル検査：自動・特定の範囲に絞り全探索 • 今回はモデル検査に焦点を当てる ◦ 分散システムの状態を「上手く」探索したい
24. オートマトンと検査 2
25. 例：二相コミット
26. Transaction Mamager Resource Mamager-1 Resource Manager-2 Resource Manager-3
27. 二相コミットのアルゴリズム (1) • TM (Transaction Manager) の視点 ◦ RM から prepared 報告を受け取ったら記録する ◦ RM に対し Commit 命令または Abort 命令を出す ◦ Commit 命令は全 RM からの prepared 報告後のみ ◦ Abort 命令はいつでも出せる ◦ 命令はブロードキャストで、相手 RM は選べない ◦ RM との通信は到達に時間がかかる
28. 二相コミットのアルゴリズム (2) • RM (Resource Manager) の視点 ◦ 他の RM とは一切通信できない ◦ 変更をコミットしたい時は TM に prepared を報告 ◦ コミット前に突然 aborted 状態になりうる ◦ TM からのCommit 命令を受け取ると変更をコミット ◦ TM からの Abort 命令を受け取ると変更を破棄 ◦ TM との通信は到達に時間がかかる
29. なるほどわからん。
30. TM RM1 RM1 : -- RM2 : -- RM3 : -- RM2 RM3
31. TM RM1 RM1 : -- RM2 : -- RM3 : -- prepared RM2 RM3
32. TM RM1 RM1 : prepared RM2 : -- RM3 : -- prepared RM2 RM3
33. TM RM1 RM1 : prepared RM2 : -- RM3 : prepared prepared prepared RM2 RM3
34. TM RM1 RM1 : prepared RM2 : prepared RM3 : prepared prepared prepared prepared RM2 RM3
35. TM RM1 RM1 : prepared RM2 : prepared RM3 : prepared prepared prepared prepared RM2 RM3
36. TM : Commit RM1 RM1 : prepared RM2 : prepared RM3 : prepared prepared prepared prepared RM2 RM3
37. TM : Commit RM1 RM1 : prepared RM2 : prepared RM3 : prepared prepared committed prepared RM2 RM3
38. TM : Commit RM1 RM1 : prepared RM2 : prepared RM3 : prepared prepared committed committed RM2 RM3
39. TM : Commit RM1 RM1 : prepared RM2 : prepared RM3 : prepared committed committed committed RM2 RM3
40. TM : Commit RM1 RM1 : prepared RM2 : prepared RM3 : prepared committed prepared aborted RM2 RM3 inconsistency!
41. もっと見通しのいい表現が欲しい
42. オートマトンとしてのプロセス • 時間を離散化して考える • 状態と遷移でプロセスを記述 ◦ 状態：その時点で変数に格納された値一式 ◦ 遷移：プログラムの実行ステップ • 例えば RM をオートマトンにすると ◦ 状態：working, prepared, committed, aborted ◦ 遷移 : TM への送信、TM からの受信
43. working aborted committed prepared
44. RM が二つ同時に動いていると
45. RM1: working RM2: working RM1: working RM2: prepared RM1: aborted RM2: working RM1: working RM2: aborted RM1: prepared RM2: working
46. RM1: working RM2: working RM1: working RM2: prepared RM1: aborted RM2: working RM1: working RM2: aborted RM1: prepared RM2: working RM1 : working -> prepared
47. RM1: working RM2: working RM1: working RM2: prepared RM1: aborted RM2: working RM1: working RM2: aborted RM1: prepared RM2: working RM2 : working -> aborted
48. オートマトンの非同期積 • 二つのオートマトンを並列に動かす ◦ 分散システムの「妥当な」形式化になっている • 積も再びオートマトンになる ◦ 状態：両方のオートマトンの状態の組 ◦ 遷移：どちらか片方のオートマトンの遷移 • システムをモジュール化して扱える ◦ 部分を次々と合成することで全体の挙動が得られる
49. TM: init RM1: working RM2: working RM3: working TM: init RM1: prepared RM2: working RM3: working TM: committed RM1: committed RM2: working RM3: aborted
50. TM: init RM1: working RM2: working RM3: working TM: init RM1: prepared RM2: working RM3: working TM: committed RM1: committed RM2: working RM3: aborted
51. TM: init RM1: working RM2: working RM3: working TM: init RM1: prepared RM2: working RM3: working TM: committed RM1: committed RM2: working RM3: aborted
52. 後は幅優先探索するだけ...か？
53. 仕様：A した後に B が成り立つ
54. Time A
55. Time A B
56. Time A B
57. Time A B B B
58. 仕様を正確に表現できる言語が必要
59. 線形時相論理（LTL） • 通常の論理式に記号を追加した体系 ◦ [] A : その時点以降、常に A が成立 ◦ <> A : その時点以降、いつかは A が成立 ◦ X A : その時点のすぐ次の時点で A が成立 • 状態の「列」に対して真偽を判定する ◦ システムの実行パスに対して条件が記述できる • Büchi オートマトンに変換して検査できる
60. Time A B [](A => <>B)
61. Time A B [](A => X B)
62. Time A B B B [](A => X ([]B))
63. 第 2 章のまとめ • オートマトンによるシステム記述 ◦ それぞれのプロセスをオートマトンで表す ◦ さらにその非同期積を取る ◦ 積も一つのオートマトンになる ◦ 有効グラフの探索問題として定式化できる • 時相論理によってあいまい性を排除 ◦ 瞬間ではなく一連の挙動を定義できる
64. 検証ツール比較 3
65. SPIN https://spinroot.com
66. SPIN の特徴 • C 言語風の文法でプロセスを記述 ◦ オートマトンを意識する必要性はあまりない ◦ ただしデータ型などはだいぶ貧弱 • チャンネルによる通信をサポート ◦ 完全な FIFO 型の通信に特化 • 検証専用の C 言語コードを出力 ◦ スケール性能を性能を追求
67. mtype = { PREPARED, COMMIT, ABORT }; bool committed[3]; bool aborted[3]; proctype TM(...) { ... } proctype RM(...) { ... } init { ... } SPIN による記述（全体）
68. mtype = { PREPARED, COMMIT, ABORT }; bool committed[3]; bool aborted[3]; proctype TM(...) { ... } proctype RM(...) { ... } init { ... } SPIN による記述（全体） 通信のタイプ
69. mtype = { PREPARED, COMMIT, ABORT }; bool committed[3]; bool aborted[3]; proctype TM(...) { ... } proctype RM(...) { ... } init { ... } SPIN による記述（全体） グローバルな条件
70. mtype = { PREPARED, COMMIT, ABORT }; bool committed[3]; bool aborted[3]; proctype TM(...) { ... } proctype RM(...) { ... } init { ... } SPIN による記述（全体） プロセスの定義
71. mtype = { PREPARED, COMMIT, ABORT }; bool committed[3]; bool aborted[3]; proctype TM(...) { ... } proctype RM(...) { ... } init { ... } SPIN による記述（全体） 初期化シーケンス
72. init { chan id_gen = [3] of { byte }; chan rm_to_tm = [3] of { mtype, byte }; chan tm_to_rm1 = [1] of { mtype }; chan tm_to_rm2 = [1] of { mtype }; chan tm_to_rm3 = [1] of { mtype }; atomic { id_gen ! 0; id_gen ! 1; id_gen ! 2; run TM(rm_to_tm, tm_to_rm1, tm_to_rm2, tm_to_rm3); run RM(rm_to_tm, tm_to_rm1, id_gen); run RM(rm_to_tm, tm_to_rm2, id_gen); run RM(rm_to_tm, tm_to_rm3, id_gen); } } SPIN による記述（初期化処理）
73. init { chan id_gen = [3] of { byte }; chan rm_to_tm = [3] of { mtype, byte }; chan tm_to_rm1 = [1] of { mtype }; chan tm_to_rm2 = [1] of { mtype }; chan tm_to_rm3 = [1] of { mtype }; atomic { id_gen ! 0; id_gen ! 1; id_gen ! 2; run TM(rm_to_tm, tm_to_rm1, tm_to_rm2, tm_to_rm3); run RM(rm_to_tm, tm_to_rm1, id_gen); run RM(rm_to_tm, tm_to_rm2, id_gen); run RM(rm_to_tm, tm_to_rm3, id_gen); } } SPIN による記述（初期化処理） チャンネルの生成
74. init { chan id_gen = [3] of { byte }; chan rm_to_tm = [3] of { mtype, byte }; chan tm_to_rm1 = [1] of { mtype }; chan tm_to_rm2 = [1] of { mtype }; chan tm_to_rm3 = [1] of { mtype }; atomic { id_gen ! 0; id_gen ! 1; id_gen ! 2; run TM(rm_to_tm, tm_to_rm1, tm_to_rm2, tm_to_rm3); run RM(rm_to_tm, tm_to_rm1, id_gen); run RM(rm_to_tm, tm_to_rm2, id_gen); run RM(rm_to_tm, tm_to_rm3, id_gen); } } SPIN による記述（初期化処理） 不可分実行
75. init { chan id_gen = [3] of { byte }; chan rm_to_tm = [3] of { mtype, byte }; chan tm_to_rm1 = [1] of { mtype }; chan tm_to_rm2 = [1] of { mtype }; chan tm_to_rm3 = [1] of { mtype }; atomic { id_gen ! 0; id_gen ! 1; id_gen ! 2; run TM(rm_to_tm, tm_to_rm1, tm_to_rm2, tm_to_rm3); run RM(rm_to_tm, tm_to_rm1, id_gen); run RM(rm_to_tm, tm_to_rm2, id_gen); run RM(rm_to_tm, tm_to_rm3, id_gen); } } SPIN による記述（初期化処理） プロセスの生成
76. proctype TM(chan ch_from, ch_to1, ch_to2, ch_to3) { byte id; bool prepared[3]; end: do :: ch_from ? PREPARED(id) -> prepared[id] = true; :: prepared[0] && prepared[1] && prepared[2] -> ch_to1 ! COMMIT; ch_to2 ! COMMIT; ch_to3 ! COMMIT; :: ch_to1 ! ABORT; ch_to2 ! ABORT; ch_to3 ! ABORT; od } SPIN による記述（TM）
77. proctype TM(chan ch_from, ch_to1, ch_to2, ch_to3) { byte id; bool prepared[3]; end: do :: ch_from ? PREPARED(id) -> prepared[id] = true; :: prepared[0] && prepared[1] && prepared[2] -> ch_to1 ! COMMIT; ch_to2 ! COMMIT; ch_to3 ! COMMIT; :: ch_to1 ! ABORT; ch_to2 ! ABORT; ch_to3 ! ABORT; od } SPIN による記述（TM） 非決定的に選択 = オートマトンが分岐
78. proctype TM(chan ch_from, ch_to1, ch_to2, ch_to3) { byte id; bool prepared[3]; end: do :: ch_from ? PREPARED(id) -> prepared[id] = true; :: prepared[0] && prepared[1] && prepared[2] -> ch_to1 ! COMMIT; ch_to2 ! COMMIT; ch_to3 ! COMMIT; :: ch_to1 ! ABORT; ch_to2 ! ABORT; ch_to3 ! ABORT; od } SPIN による記述（TM） チャンネルからの受信
79. proctype TM(chan ch_from, ch_to1, ch_to2, ch_to3) { byte id; bool prepared[3]; end: do :: ch_from ? PREPARED(id) -> prepared[id] = true; :: prepared[0] && prepared[1] && prepared[2] -> ch_to1 ! COMMIT; ch_to2 ! COMMIT; ch_to3 ! COMMIT; :: ch_to1 ! ABORT; ch_to2 ! ABORT; ch_to3 ! ABORT; od } SPIN による記述（TM） prepared が揃っているか
80. proctype TM(chan ch_from, ch_to1, ch_to2, ch_to3) { byte id; bool prepared[3]; end: do :: ch_from ? PREPARED(id) -> prepared[id] = true; :: prepared[0] && prepared[1] && prepared[2] -> ch_to1 ! COMMIT; ch_to2 ! COMMIT; ch_to3 ! COMMIT; :: ch_to1 ! ABORT; ch_to2 ! ABORT; ch_to3 ! ABORT; od } SPIN による記述（TM） Commit 命令を一斉送信
81. proctype TM(chan ch_from, ch_to1, ch_to2, ch_to3) { byte id; bool prepared[3]; end: do :: ch_from ? PREPARED(id) -> prepared[id] = true; :: prepared[0] && prepared[1] && prepared[2] -> ch_to1 ! COMMIT; ch_to2 ! COMMIT; ch_to3 ! COMMIT; :: ch_to1 ! ABORT; ch_to2 ! ABORT; ch_to3 ! ABORT; od } SPIN による記述（TM） Abort 命令を一斉送信
82. proctype RM(chan ch_to, ch_from, id_gen) { byte id; id_gen ? id; if :: ch_to ! PREPARED(id) -> if :: ch_from ? COMMIT -> committed[id] = true; :: ch_from ? ABORT -> aborted[id] = true; fi :: aborted[id] = true; fi } SPIN による記述（RM）
83. proctype RM(chan ch_to, ch_from, id_gen) { byte id; id_gen ? id; if :: ch_to ! PREPARED(id) -> if :: ch_from ? COMMIT -> committed[id] = true; :: ch_from ? ABORT -> aborted[id] = true; fi :: aborted[id] = true; fi } SPIN による記述（RM） 自分の id を TM に送信
84. proctype RM(chan ch_to, ch_from, id_gen) { byte id; id_gen ? id; if :: ch_to ! PREPARED(id) -> if :: ch_from ? COMMIT -> committed[id] = true; :: ch_from ? ABORT -> aborted[id] = true; fi :: aborted[id] = true; fi } SPIN による記述（RM） 受信結果で対応が変わる
85. TLA+ https://lamport.azumewebsites.net/tla/tla.html
86. TLA+ の特徴 • 生のオートマトンでシステムを記述 ◦ 状態遷移の条件を直接記述 ◦ プロセスごとではなく全体をまとめて記述する • プログラム的な記述は DSL (+CAL) でサポート ◦ 自動でアルゴリズムをオートマトンに変換 • GUI 環境が非常によく整っている
87. CONSTANT RM VARIABLES rmState, tmState, tmPrepare, msgs Message == [type : {“Prepared”}, rm : RM] \union [type : {“Commit”, “Abort”}] Init == /\ rmState = [rm \in RM |-> “working”] /\ tmState = “init” /\ tmPrepare = {} /\ msgs = {} TLA+ による記述（全体）
88. CONSTANT RM VARIABLES rmState, tmState, tmPrepare, msgs Message == [type : {“Prepared”}, rm : RM] \union [type : {“Commit”, “Abort”}] Init == /\ rmState = [rm \in RM |-> “working”] /\ tmState = “init” /\ tmPrepare = {} /\ msgs = {} TLA+ による記述（全体） （個数を限定しない）RM の集合
89. CONSTANT RM VARIABLES rmState, tmState, tmPrepare, msgs Message == [type : {“Prepared”}, rm : RM] \union [type : {“Commit”, “Abort”}] Init == /\ rmState = [rm \in RM |-> “working”] /\ tmState = “init” /\ tmPrepare = {} /\ msgs = {} TLA+ による記述（全体） 状態はすべてグローバル
90. CONSTANT RM VARIABLES rmState, tmState, tmPrepare, msgs Message == [type : {“Prepared”}, rm : RM] \union [type : {“Commit”, “Abort”}] Init == /\ rmState = [rm \in RM |-> “working”] /\ tmState = “init” /\ tmPrepare = {} /\ msgs = {} TLA+ による記述（全体） 初期状態
91. Next == /\ TMCommit /\ TMAbort /\ \E rm \in RM : \/ TMRcvPrepared(rm) \/ RMPrepare(rm) \/ RMChooseToAbort(rm) \/ RMRcvCommitMsg(rm) \/ RMRcvAbortMsg(rm) TLA+ による記述（全体）
92. Next == /\ TMCommit /\ TMAbort /\ \E rm \in RM : \/ TMRcvPrepared(rm) \/ RMPrepare(rm) \/ RMChooseToAbort(rm) \/ RMRcvCommitMsg(rm) \/ RMRcvAbortMsg(rm) TLA+ による記述（全体） 可能な遷移の全体
93. TMRcvPrepared(rm) == /\ tmState = “init” /\ [type |-> “Prepared”, rm |-> rm] \in msgs /\ tmPrepared’ = tmPrepared \union {rm} /\ UNCHANGED <<tmState, rmState, msgs>> TMCommit == /\ rmState = “init” /\ tmPrepared = RM /\ rmState’ = “committed” /\ msgs’ = msgs \union {[type |-> “Commit”]} /\ UNAHGEND <<rmState, tmState>> TMAbort == ... TLA+ による記述（TM）
94. TMRcvPrepared(rm) == /\ tmState = “init” /\ [type |-> “Prepared”, rm |-> rm] \in msgs /\ tmPrepared’ = tmPrepared \union {rm} /\ UNCHANGED <<tmState, rmState, msgs>> TMCommit == /\ rmState = “init” /\ tmPrepared = RM /\ rmState’ = “committed” /\ msgs’ = msgs \union {[type |-> “Commit”]} /\ UNAHGEND <<rmState, tmState>> TMAbort == ... TLA+ による記述（TM） TM が Commit 命令を送信
95. TMRcvPrepared(rm) == /\ tmState = “init” /\ [type |-> “Prepared”, rm |-> rm] \in msgs /\ tmPrepared’ = tmPrepared \union {rm} /\ UNCHANGED <<tmState, rmState, msgs>> TMCommit == /\ rmState = “init” /\ tmPrepared = RM /\ rmState’ = “committed” /\ msgs’ = msgs \union {[type |-> “Commit”]} /\ UNAHGEND <<rmState, tmState>> TMAbort == ... TLA+ による記述（TM） 「‘」をつけると遷移先を意味する
96. RMPrepare(rm) == /\ rmState[rm] = “working” /\ rmState’ = [rmState EXCEPT ![rm] = “prepared”] /\ msgs’ = msgs \union {[type |-> “Prepared”, rm |-> rm]} /\ UNCHANGED <<tmState, tmPrepared>> RMChooseAbort(rm) == ... RMRcvCommitMsg(rm) == /\ [type |-> “Commit”] \in msgs /\ rmState’ = [rmState EXCEPT ![rm] = “committed”] /\ UNCHANGED <<tmState, tmPrepared, msgs>> RMRcvAbortMsg(rm) == ... TLA+ による記述（RM）
97. P https://github.com/p-org/P
98. P 言語の特徴 • 状態とハンドラの組でプロセスを記述 ◦ Web フレームワークの Controller に近い • 各プロセスが入力用のキューを持つ ◦ SPIN と異なりキューはプロセスの持ち物 ◦ 他のプロセスからのメッセージがキューに積まれる • 実行可能な C 言語のコードを出力
99. event PREPARE: machine; event COMMIT; event ABORT; machine TM { ... } machine RM { ... } P による記述（全体）
100. event PREPARE: machine; event COMMIT; event ABORT; machine TM { ... } machine RM { ... } P による記述（全体） メッセージの種類
101. event PREPARE: machine; event COMMIT; event ABORT; machine TM { ... } machine RM { ... } P による記述（全体） プロセスの定義
102. machine TM { var rms: seq[machine]; var prepared: map[machine, bool]; start state Init { on PREPARE (rm: machine) { prepared[rm] = true; if (sizeof(prepared) == sizeof(rms)) { SendCommitMsg(); goto Committed; } } } state Committed {} state Aborted {} } P による記述（TM）
103. machine TM { var rms: seq[machine]; var prepared: map[machine, bool]; start state Init { on PREPARE (rm: machine) { prepared[rm] = true; if (sizeof(prepared) == sizeof(rms)) { SendCommitMsg(); goto Committed; } } } state Committed {} state Aborted {} } P による記述（TM） 状態の定義
104. machine TM { var rms: seq[machine]; var prepared: map[machine, bool]; start state Init { on PREPARE (rm: machine) { prepared[rm] = true; if (sizeof(prepared) == sizeof(rms)) { SendCommitMsg(); goto Committed; } } } state Committed {} state Aborted {} } P による記述（TM） PREPARE メッセージをデキュー
105. machine TM { var rms: seq[machine]; var prepared: map[machine, bool]; start state Init { on PREPARE (rm: machine) { prepared[rm] = true; if (sizeof(prepared) == sizeof(rms)) { SendCommitMsg(); goto Committed; } } } state Committed {} state Aborted {} } P による記述（TM） 関数を実行して次の状態へ
106. machine TM { ... start state Init { ... } state Committed {} state Aborted {} fun SendCommitMsg() { var i: int; i = 0; while (i < sizeof(rms)) { send rms[i], COMMIT; i = i + 1; } } } P による記述（TM）
107. machine TM { ... start state Init { ... } state Committed {} state Aborted {} fun SendCommitMsg() { var i: int; i = 0; while (i < sizeof(rms)) { send rms[i], COMMIT; i = i + 1; } } } P による記述（TM） すべての RM に COMMIT 命令
108. machine RM { start state Working { ... } state Prepare { ... } state Committed {} state Aborted {} } P による記述（RM）
109. machine RM { start state Working { entry (tm: machine) { if ($) { send tm, PREPARE, this; goto Prepare; } else { goto Aborted; } } on Commit { goto Committed; } } } P による記述（RM）
110. machine RM { start state Working { entry (tm: machine) { if ($) { send tm, PREPARE, this; goto Prepare; } else { goto Aborted; } } on Commit { goto Committed; } } } P による記述（RM） 非決定的な真偽値 = オートマトンの分岐
111. machine RM { start state Working { entry (tm: machine) { if ($) { send tm, PREPARE, this; goto Prepare; } else { goto Aborted; } } on Commit { goto Committed; } } } P による記述（RM） メッセージが送信され、 TM のキューに積まれる
112. LTL による検査のサポート • SPIN ◦ 可能だが、検査したい式の否定を入力する必要あり • TLA+ ◦ 完全なサポート、システム定義側でも使用可 • P 言語 ◦ サポートなし、検査したい内容を machine で表現 ◦ 場合によっては複雑な変換が必要になる
113. 第 3 章のまとめ • SPIN ◦ チャンネルを介して通信するプロセスを定義 • TLA+ ◦ システム全体の状態遷移の条件を明示的に定義 ◦ +CAL を使用すると手続き的な記述もできる • P 言語 ◦ 各状態とイベントに対するリアクションを定義
114. 本日のまとめ 4
115. 本日のまとめ • 分散システムの検証に形式手法が有効 ◦ 考えるパターンが多く人の手では扱えない • オートマトンを基礎としたモデル検査 ◦ 形式化・抽象化による体系的な状態の列挙 ◦ 時相論理により、表現しづらい仕様を明示 • 各モデル検査ツールの特徴 ◦ どれもクセがあるのでシステムの性質に合わせて選ぶ
116. Cool Head, and Formal Heart. Presented by チェシャ猫 (@y_taka_23)