comparison Paper/tex/dpp_impl.tex @ 17:785dd684c529

Fix
author soto <soto@cr.ie.u-ryukyu.ac.jp>
date Thu, 02 Feb 2023 20:52:51 +0900 (2023-02-02)
parents 40a9af45b375
children 1b000d9505f5
comparison
equal deleted inserted replaced
16:40a9af45b375 17:785dd684c529
1 \section{Gears Agdaによるモデル検査の流れ} 1 \section{Gears Agdaによるモデル検査の流れ}
2 今回作成した Gears Agda による DPP のモデル検査の流れは以下のようになっている. 2 今回作成した Gears Agda による DPP のモデル検査の流れは以下のようになっている。
3 3
4 \begin{enumerate} 4 \begin{enumerate}
5 \item Gears Agda にて DPP の実装を行う 5 \item Gears Agda にて DPP の実装を行う
6 \item プログラムが実行中に取りうる状態の網羅をする State List を作成する 6 \item プログラムが実行中に取りうる状態の網羅をする State List を作成する
7 \item 上で実装したものを使用しつつ Meta Data Gear を構築する Meta Code Gearを記述する 7 \item 上で実装したものを使用しつつ Meta DataGear を構築する Meta CodeGearを記述する
8 \item 上記 Meta Code Gear で作成された meta data を元に,dead lockを判定する Meta Code Gear を記述する 8 \item 上記 Meta CodeGear で作成された meta data を元に,dead lockを判定する Meta CodeGear を記述する
9 \item 状態を網羅した State List にある State を一つずつ Meta Code Gear に実行させて,dead lockしている状態がないか確認する 9 \item 状態を網羅した State List にある State を一つずつ Meta CodeGear に実行させて,dead lockしている状態がないか確認する
10 \end{enumerate} 10 \end{enumerate}
11 11
12 先行研究では網羅した状態データを State DB に格納していた.しかし今回の Gears Agda では State List にて代替とした.これは List で行った方が Agda での実装がしやすい点にある.本来は branced tree をデータ構造に持って State を作成するほう正しい. 12 先行研究では網羅した状態データを State DB に格納していた。しかし今回の Gears Agda では State List にて代替とした。これは List で行った方が Agda での実装がしやすい点にある。本来は branced tree をデータ構造に持って State を作成するほう正しい。
13 13
14 dead lock の定義として,全てのプロセスが他のプロセスの実行終了待ちをしている.かつ新たに状態の分岐が作成できないものとした. 14 dead lock の定義として,全てのプロセスが他のプロセスの実行終了待ちをしている。かつ新たに状態の分岐が作成できないものとした。
15 そこでstep実行してもプロセスがすべて変動がなく,かつStateの分岐が作成されなかったものを dead lock としている. 15 そこでstep実行してもプロセスがすべて変動がなく,かつStateの分岐が作成されなかったものを dead lock としている。
16 16
17 最後について,今回は状態の網羅を一度終了してから dead lock の有無を検証している.しかし,これは今回のプログラムが有限オートマトンであることは事前に明らかであるためにできたことである.検証したいプログラムが無限の状態を作成する場合は,Stateを作成するたびにそれに対して dead lock や live lock などのモデル検査をすることもできる.モデル検査中に意図しない動きがあった場合に停止するようにすることで,無限の状態を作成するプログラムであっても,モデル検査ができると考える.他にも,プログラムが取る状態を制限することで有限な状態を作成するようにし,モデル検査をすることもできる. (bounded model checking) 17 最後について,今回は状態の網羅を一度終了してから dead lock の有無を検証している。しかし,これは今回のプログラムが有限オートマトンであることは事前に明らかであるためにできたことである。検証したいプログラムが無限の状態を作成する場合は,Stateを作成するたびにそれに対して dead lock や live lock などのモデル検査をすることもできる。モデル検査中に意図しない動きがあった場合に停止するようにすることで,無限の状態を作成するプログラムであっても,モデル検査ができると考える。他にも,プログラムが取る状態を制限することで有限な状態を作成するようにし,モデル検査をすることもできる。 (bounded model checking)
18 18
19 \section{Gears Agda によるDPPの実装} 19 \section{Gears Agda によるDPPの実装}
20 20
21 DPP の記述の主要部分を示し,説明する. 21 DPP の記述の主要部分を示し、説明する。
22 22
23 \lstinputlisting[caption= Gears Agdaでの DPP の 哲学者の状態 , label=agda-dpp-state, lastline=7]{src/agda-dpp-impl.agda.replaced} 23 \lstinputlisting[caption= Gears Agdaでの DPP の 哲学者の状態 , label=code:agda-dpp-state, lastline=7]{src/agda-dpp-impl.agda.replaced}
24 24
25 \lstinputlisting[caption= Gears Agdaでの DPP の プロセス , label=agda-dpp-process, firstline=9, lastline=16]{src/agda-dpp-impl.agda.replaced} 25 \lstinputlisting[caption= Gears Agdaでの DPP の プロセス , label=code:agda-dpp-process, firstline=9, lastline=16]{src/agda-dpp-impl.agda.replaced}
26 26
27 \lstinputlisting[caption= Gears Agdaでの DPP の Data Gear , label=agda-dpp-dg, firstline=17, lastline=21]{src/agda-dpp-impl.agda.replaced} 27 \lstinputlisting[caption= Gears Agdaでの DPP の DataGear , label=code:agda-dpp-dg, firstline=17, lastline=21]{src/agda-dpp-impl.agda.replaced}
28 28
29 Code \ref{agda-dpp-state}は 29 \coderef{agda-dpp-state}は
30 前述した哲学者の状態を書き記して,哲学者が今行おうとしている動作を網羅している. 30 前述した哲学者の状態を書き記して、哲学者が今行おうとしている動作を網羅している。
31 31
32 Code \ref{agda-dpp-process}は 32 \coderef{agda-dpp-process}は
33 哲学者一人ずつの環境を持っている. 33 哲学者一人ずつの環境を持っている。
34 pid はその哲学者がどこに座っているかの識別子で, 34 pid はその哲学者がどこに座っているかの識別子で、
35 right / left hand はフォークを手に持っているかを格納している. 35 right / left hand はフォークを手に持っているかを格納している。
36 next-code は次に行う動作を格納している. 36 next-code は次に行う動作を格納している。
37 37
38 Code \ref{agda-dpp-dg} が Data Gear になる. 38 \coderef{agda-dpp-dg} が DataGear になる。
39 phは前もって定義した一人の哲学者のプロセスの List になる. 39 phは前もって定義した一人の哲学者のプロセスの List になる。
40 List になっている理由は,哲学者が複数人いるためである. 40 List になっている理由は、哲学者が複数人いるためである。
41 そのため実行時にListから一人ずつ取り出して実行をしていく. 41 そのため実行時にListから一人ずつ取り出して実行をしていく。
42 42
43 tableはテーブルに置いてあるフォークの状態のことで, 43 tableはテーブルに置いてあるフォークの状態のことで、
44 pid が1の人の右側にあるフォークが List の最初にあり, 44 pid が1の人の右側にあるフォークが List の最初にあり、
45 pid が1の人の左側にあるフォーク,すなわち pid が2の人の右側にあるフォークが 45 pid が1の人の左側にあるフォーク、すなわち pid が2の人の右側にあるフォークが
46 その次の List に格納されていくようになっている. 46 その次の List に格納されていくようになっている。
47 また,自然数の List になっているが, 47 また、自然数の List になっているが、
48 その場所のフォークがテーブルの上にある場合は自然数の0が, 48 その場所のフォークがテーブルの上にある場合は自然数の0が、
49 誰かが所持している場合はその人の pid が格納されるようになっている. 49 誰かが所持している場合はその人の pid が格納されるようになっている。
50 50
51 \lstinputlisting[caption= Gears Agdaでの DPP の Data Gear のinit, label=agda-dpp-init, firstline=23, lastline=30]{src/agda-dpp-impl.agda.replaced} 51 \lstinputlisting[caption= Gears Agdaでの DPP の DataGear のinit, label=code:agda-dpp-init, firstline=23, lastline=30]{src/agda-dpp-impl.agda.replaced}
52 52
53 Code \ref{agda-dpp-init}が入力から Data Gear を作成する Code Gear になる. 53 \coderef{agda-dpp-init}が入力から DataGear を作成する CodeGear になる。
54 ここでは哲学者の人数を自然数で受け取り,人数分の List Phi と table を一つずつ作成し env を作成している. 54 ここでは哲学者の人数を自然数で受け取り、人数分の List Phi と table を一つずつ作成し env を作成している。
55 また,最初の哲学者の状態は思考することであるため,next-code には C\_thinking を格納している. 55 また、最初の哲学者の状態は思考することであるため、next-code には C\_thinking を格納している。
56 56
57 \lstinputlisting[caption= Gears Agdaでの DPP の step 実行, label=agda-dpp-step, firstline=31, lastline=37]{src/agda-dpp-impl.agda.replaced} 57 \lstinputlisting[caption= Gears Agdaでの DPP の step 実行, label=agda-dpp-step, firstline=31, lastline=37]{src/agda-dpp-impl.agda.replaced}
58 58
59 Agda では並列実行を行うことができない.そのため step 単位の実行を一つずつ行うことで 59 Agda では並列実行を行うことができない。そのため step 単位の実行を一つずつ行うことで
60 並列実行をしていることとする. 60 並列実行をしていることとする。
61 61
62 この際に Env にある List Phi の中身を展開しながら一つずつ行動を処理していく. 62 この際に Env にある List Phi の中身を展開しながら一つずつ行動を処理していく。
63 63
64 \lstinputlisting[caption=Gears Agdaでの DPP の左のフォークを取る記述, label=agda-dpp-lfork, firstline=39]{src/agda-dpp-impl.agda.replaced} 64 \lstinputlisting[caption=Gears Agdaでの DPP の左のフォークを取る記述, label=code:agda-dpp-lfork, firstline=39]{src/agda-dpp-impl.agda.replaced}
65 65
66 Code \ref{agda-dpp-lfork}が step 実行をした際に哲学者が左側のフォークを取る記述になる. 66 \coderef{agda-dpp-lfork}が step 実行をした際に哲学者が左側のフォークを取る記述になる。
67 67
68 左側のフォークを取る際には table の index は pid の次の値になっている. 68 左側のフォークを取る際には table の index は pid の次の値になっている。
69 図 \ref{fig:DPP} を見ると直感的に理解ができる. 69 \figref{DPP} を見ると直感的に理解ができる。
70 70
71 最後の哲学者は一番最初のフォークを参照する必要がある. 71 最後の哲学者は一番最初のフォークを参照する必要がある。
72 フォークの状態を確認し,値が0である場合はフォークがテーブルの上にあるので 72 フォークの状態を確認し、値が0である場合はフォークがテーブルの上にあるので
73 それを自分の pid に書き換える。次に left-hand を true に書き換えて手に持つ 73 それを自分の pid に書き換える。次に left-hand を true に書き換えて手に持つ
74 フォークの状態が0以外,すなわち他の哲学者がその場所のフォークを取得している場合は 74 フォークの状態が0以外、すなわち他の哲学者がその場所のフォークを取得している場合は
75 状態を変化させずに処理を続ける. 75 状態を変化させずに処理を続ける。
76 このように左のフォークを取る記述をした. 76 このように左のフォークを取る記述をした。
77 77
78 右側のフォークを取る場合は引数の部分を1足さずにそのまま受け取る. 78 右側のフォークを取る場合は引数の部分を1足さずにそのまま受け取る。
79 比較するべき table の List と哲学者のListは一致しているため,pickup\_lfork のように最後の哲学者が 79 比較するべき table の List と哲学者のListは一致しているため、pickup\_lfork のように最後の哲学者が
80 最初のフォークを参照することもない. 80 最初のフォークを参照することもない。
81 81
82 似たような形で哲学者がフォークを置く putdown-lfork/rfork を実装した. 82 似たような形で哲学者がフォークを置く putdown-lfork/rfork を実装した。
83 思考と食事の実装に関してはそのまま状態を変更することなく進むようにしている. 83 思考と食事の実装に関してはそのまま状態を変更することなく進むようにしている。
84 84
85 \section{Gears Agda によるDPPの検証} 85 \section{Gears Agda によるDPPの検証}
86 86
87 これまでの実装は一般的なDPPの実装であったため, 87 これまでの実装は一般的なDPPの実装であったため,
88 Code / Data Gear の実装であった. 88 Code / DataGear の実装であった。
89 ここからは,モデル検査を行うため,Meta Data Gear の定義をし, 89 ここからは,モデル検査を行うため,Meta DataGear の定義をし,
90 それの操作を行う Meta Code Gear の実装を行っていく. 90 それの操作を行う Meta CodeGear の実装を行っていく。
91 91
92 以下\coderef{dpp-mdg}がMeta Data Gear の定義になる。 92 以下\coderef{dpp-mdg}がMeta DataGear の定義になる。
93 93
94 % ここにmetadata MetaEnv MetaEnv2のソースコードを貼り付ける 94 % ここにmetadata MetaEnv MetaEnv2のソースコードを貼り付ける
95 \lstinputlisting[caption=Gears Agda で DPP のモデル検査を行うための Meta Data Gear, label=code:dpp-mdg]{src/dpp-verif/dpp-metadata.agda.replaced} 95 \lstinputlisting[caption=Gears Agda で DPP のモデル検査を行うための Meta DataGear, label=code:dpp-mdg]{src/dpp-verif/dpp-metadata.agda.replaced}
96 96
97 この Meta Data Gear の説明をすると, 97 この Meta DataGear の説明をすると,
98 metadataは状態の分岐数を持っておくnum-brunchがある. 98 metadataは状態の分岐数を持っておくnum-brunchがある。
99 MetaEnv はもとの DataGear を保持するDG(Data Gearの省略)となる。 99 MetaEnv はもとの DataGear を保持するDG(DataGearの省略)となる。
100 meta には前述したmetadataを持っており, 100 meta には前述したmetadataを持っており,
101 他には,deadlockしているかのフラグである deadlock , 101 他には,deadlockしているかのフラグである deadlock ,
102 最後の2つは後に必要になるフラグである。 102 最後の2つは後に必要になるフラグである。
103 そのstate が step 実行済みなのかのフラグであるis-step, 103 そのstate が step 実行済みなのかのフラグであるis-step,
104 そのstateがモデル検査済なのかのフラグであるis-doneフラグを持っている. 104 そのstateがモデル検査済なのかのフラグであるis-doneフラグを持っている。
105 105
106 MetaEnv2 は1つのstate である MetaEnv の Listを metal で持てる. 106 MetaEnv2 は1つのstate である MetaEnv の Listを metal で持てる。
107 加えて今まで実行していた Data Gear を DG で持てる. 107 加えて今まで実行していた DataGear を DG で持てる。
108 108
109 次に Meta Data Gear を作成する Meta Code Gear の説明をする。 109 次に Meta DataGear を作成する Meta CodeGear の説明をする。
110 110
111 \begin{enumerate} 111 \begin{enumerate}
112 \item その状態から分岐できる状態数をカウントする Meta Code Gear 112 \item その状態から分岐できる状態数をカウントする Meta CodeGear
113 \item Wait List を作成する Meta Code Gear 113 \item Wait List を作成する Meta CodeGear
114 \end{enumerate} 114 \end{enumerate}
115 115
116 以下の \coderef{dpp-mcg-branch} が分岐できる状態数をカウントする Meta Code Gear となる。 116 以下の \coderef{dpp-mcg-branch} が分岐できる状態数をカウントする Meta CodeGear となる。
117 117
118 %ここにコードを載せる% 118 %ここにコードを載せる%
119 \lstinputlisting[caption=状態の分岐数をカウントする Meta Data Gear の定義, label=code:dpp-mcg-branch]{src/dpp-verif/dpp-metacode.agda.replaced} 119 \lstinputlisting[caption=状態の分岐数をカウントする Meta DataGear の定義, label=code:dpp-mcg-branch]{src/dpp-verif/dpp-metacode.agda.replaced}
120 120
121 121
122 実際にやっていることは,MetaEnv2 から state を取り出し,分岐を見る関数に遷移させている.その結果の List の length を meta データとしている. 122 実際にやっていることは,MetaEnv2 から state を取り出し,分岐を見る関数に遷移させている。その結果の List の length を meta データとしている。
123 123
124 つまり,この Meta Code Gear の実装にあたって新しい実装はほとんど行っていない. 124 つまり,この Meta CodeGear の実装にあたって新しい実装はほとんど行っていない。
125 125
126 Wait List の 作成も同じように取り出した state を step させて,そこで一致するnext-codeを状態が変わっていないとして Wait List に入れている. 126 Wait List の 作成も同じように取り出した state を step させて,そこで一致するnext-codeを状態が変わっていないとして Wait List に入れている。
127 127
128 %いちおうコード載せようかな?←棄却されました% 128 %いちおうコード載せようかな?←棄却されました%
129 129
130 Wait List について,Thinking と Eathing の状態に関しては状態が変わる可能性がある. 130 Wait List について,Thinking と Eathing の状態に関しては状態が変わる可能性がある。
131 これを Wait List に入れなければ Wait List のみで dead lock が検知できると考えられる.しかし,DPP以外の他のプログラムをモデル検査する際に,一つ一つ next-code の設定を行うのは煩雑であると考えた.そのため,step した際に状態が変化しないものを Wait List にいれた.これと分岐がない場合という条件にて,dead lock を検知する.これにより Meta Code Gear の作成が簡易化された.そのため,Thinking と Eathing のプロセスも Waithing List に入るようになっている. 131 これを Wait List に入れなければ Wait List のみで dead lock が検知できると考えられる。しかし,DPP以外の他のプログラムをモデル検査する際に,一つ一つ next-code の設定を行うのは煩雑であると考えた。そのため,step した際に状態が変化しないものを Wait List にいれた。これと分岐がない場合という条件にて,dead lock を検知する。これにより Meta CodeGear の作成が簡易化された。そのため,Thinking と Eathing のプロセスも Waithing List に入るようになっている。
132 132
133 deadlockの検出方法として,上記の2つのMeta Code Gear で作成したmeta データを使用する. 133 deadlockの検出方法として,上記の2つのMeta CodeGear で作成したmeta データを使用する。
134 134
135 そして「num-brunchの値が1であり,wait Listの数がプロセス数と一致する」ということは,「その状態から別の状態に遷移することができない」として,この状態をdead lockであると定義した. 135 そして「num-brunchの値が1であり,wait Listの数がプロセス数と一致する」ということは,「その状態から別の状態に遷移することができない」として,この状態をdead lockであると定義した。
136 136
137 以下の\coderef{dpp-judge-mcg}がdead-lockを検知する関数となる。 137 以下の\coderef{dpp-judge-mcg}がdead-lockを検知する関数となる。
138 138
139 複雑なことは何もしておらず,単純にstate毎のnum-brunchの値を見て,wait-listの数がプロセス数と一致していた場合に 139 複雑なことは何もしておらず,単純にstate毎のnum-brunchの値を見て,wait-listの数がプロセス数と一致していた場合に
140 deadlockのフラグを立ち上げている.これが,Gears Agda におけるアサーションになっている. 140 deadlockのフラグを立ち上げている。これが,Gears Agda におけるアサーションになっている。
141 141
142 % judge-dead-lock-pのソースコードを貼り付ける 142 % judge-dead-lock-pのソースコードを貼り付ける
143 \lstinputlisting[caption=DPP での dead lock を検知する Meta Code Gear, label=code:dpp-judge-mcg]{src/dpp-verif/judge-deadlock.agda.replaced} 143 \lstinputlisting[caption=DPP での dead lock を検知する Meta CodeGear, label=code:dpp-judge-mcg]{src/dpp-verif/judge-deadlock.agda.replaced}
144 % こいつはmetaEnv2を受け取れるように変えないと行けない 144 % こいつはmetaEnv2を受け取れるように変えないと行けない
145 145
146 ここから前述した通り,State Listを作成する. 146 ここから前述した通り,State Listを作成する。
147 147
148 そのまま実行するだけでは無限に実行されるのみで停止しないと思われる. 148 そのまま実行するだけでは無限に実行されるのみで停止しないと思われる。
149 しかし,分岐後に step 実行後の state を保存している State List に同じ State が存在しないかを確かめる. 149 しかし,分岐後に step 実行後の state を保存している State List に同じ State が存在しないかを確かめる。
150 存在していた場合はそれを追加せず,存在しなかった場合にのみ State を追加する. 150 存在していた場合はそれを追加せず,存在しなかった場合にのみ State を追加する。
151 151
152 Agdaには2つの record が等しいか確かめる関数などは存在せず, 152 Agdaには2つの record が等しいか確かめる関数などは存在せず,
153 \coderef{dpp-exclude-state-mcg} のようにrecordの中身を一つずつ一致しているか確認する. 153 \coderef{dpp-exclude-state-mcg} のようにrecordの中身を一つずつ一致しているか確認する。
154 こちらはそのまま掲載すると長いので,実際のコードに手を加えて省略している.実際のコードは付録にて参照できる. 154 こちらはそのまま掲載すると長いので,実際のコードに手を加えて省略している。実際のコードは付録にて参照できる。
155 155
156 \lstinputlisting[caption=重複しているstateを除外する Meta Code Gear, label=code:dpp-exclude-state-mcg]{src/dpp-verif/exclude-same-env.agda.replaced} 156 \lstinputlisting[caption=重複しているstateを除外する Meta CodeGear, label=code:dpp-exclude-state-mcg]{src/dpp-verif/exclude-same-env.agda.replaced}
157 % 手を加えているので詳細は付録を参照するように促す 157 % 手を加えているので詳細は付録を参照するように促す
158 158
159 MetaEnv2 を受け取ってその中身の state を比較するが,そこまで展開する必要がある. 159 MetaEnv2 を受け取ってその中身の state を比較するが,そこまで展開する必要がある。
160 loop-metaenv と loop-target-metaenv, eq-env にてそれを行っている. 160 loop-metaenv と loop-target-metaenv, eq-env にてそれを行っている。
161 161
162 更に15行目の loop-metaenv では State List 内に見つからなかった場合に State List に Stateを追加し,次のstateの一致を探索するように記述されている. 162 更に15行目の loop-metaenv では State List 内に見つからなかった場合に State List に Stateを追加し,次のstateの一致を探索するように記述されている。
163 163
164 実際にstateの一致を見ているのは22行目のeq-env関数で,一致している State が見つかった場合には追加せずにこちらも次の State を探索するように記述されている。 164 実際にstateの一致を見ているのは22行目のeq-env関数で,一致している State が見つかった場合には追加せずにこちらも次の State を探索するように記述されている。
165 165
166 State が保持している値がそれぞれ正しいのかは eq-pid のように一致を見て分岐させている. 166 State が保持している値がそれぞれ正しいのかは eq-pid のように一致を見て分岐させている。
167 その値が一致している場合には別の値を見て,一致していない場合はeq-envに遷移して State List にある次の State との一致を見るようにしている. 167 その値が一致している場合には別の値を見て,一致していない場合はeq-envに遷移して State List にある次の State との一致を見るようにしている。
168 他の値である,lhandやrhandなども eq-pid と同じように記述している. 168 他の値である,lhandやrhandなども eq-pid と同じように記述している。
169 169
170 170
171 これらにて,まだ分岐を見ていない1つのStateの分岐を確かめる. 171 これらにて,まだ分岐を見ていない1つのStateの分岐を確かめる。
172 発生した分岐を step 実行させる. 172 発生した分岐を step 実行させる。
173 step実行して作成された state が State Listに存在していないかを確かめる. 173 step実行して作成された state が State Listに存在していないかを確かめる。
174 これを繰り返すことで State Listを作る. 174 これを繰り返すことで State Listを作る。
175 State List に存在している全ての state の分岐を見たということは, 175 State List に存在している全ての state の分岐を見たということは,
176 出現するStateを全て網羅することができたと言える. 176 出現するStateを全て網羅することができたと言える。
177 177
178 あとは State List を dead lock の検査を行う Meta Code Gear に与えるとどの state が dead lockしているかを検証することができる。 178 あとは State List を dead lock の検査を行う Meta CodeGear に与えるとどの state が dead lockしているかを検証することができる。
179 179
180 \section{Gears Agda による live lockの検証方法について} 180 \section{Gears Agda による live lockの検証方法について}
181 live lockとは,状態が変動しているが,その状態はループしており,実行が進んでいないことを指す. 181 live lockとは,状態が変動しているが,その状態はループしており,実行が進んでいないことを指す。
182 182
183 DPPにて例を上げると,(上の哲学者のフローだと) dead lock が発生するため,フローを変更したとする.それは以下のような動作を追加する. 183 DPPにて例を上げると,(上の哲学者のフローだと) dead lock が発生するため,フローを変更したとする。それは以下のような動作を追加する。
184 「右手にフォークを持っているが,左手のフォークがすでに取られている場合に右手のフォークを即座に置いて固定時間待つ」 184 「右手にフォークを持っているが,左手のフォークがすでに取られている場合に右手のフォークを即座に置いて固定時間待つ」
185 とする.これで解決すると思われるが,全員が同時に食事をしようとした場合,右手のフォークを取ったり置いたりを永遠に繰り返すことになる. 185 とする。これで解決すると思われるが,全員が同時に食事をしようとした場合,右手のフォークを取ったり置いたりを永遠に繰り返すことになる。
186 これを live lock という 186 これを live lock という
187 187
188 つまり,この状態を検知するなら,そのstateが持っているhistoryまで考慮する必要がある.つまり,今回の場合だとstateのloopができた際にコマンドが一巡しているかを確認すると良い. 188 つまり,この状態を検知するなら,そのstateが持っているhistoryまで考慮する必要がある。つまり,今回の場合だとstateのloopができた際にコマンドが一巡しているかを確認すると良い。
189 189
190 history がloopしていた際に,誰もeathingしていない場合を live lock していると定義する. 190 history がloopしていた際に,誰もeathingしていない場合を live lock していると定義する。
191 191
192 今回のはDPPであるためEatingが挙げられているが,他の実装であれば,どのコマンドが実行されるのが正常な動きなのかを決める.それがloop中に存在しているかを確認することで live lock を検知できる. 192 今回のはDPPであるためEatingが挙げられているが,他の実装であれば,どのコマンドが実行されるのが正常な動きなのかを決める。それがloop中に存在しているかを確認することで live lock を検知できる。
193 193
194 194
195 \section{Gears Agda でのモデル検査の評価} 195 \section{Gears Agda でのモデル検査の評価}
196 196
197 SPINで行ったDPPのモデル検査に比べると,Gears Agdaの方がコードも長く、制約が多いため難解に思える.しかし,Gears Agda ではプログラムの実装も含んでいる. 197 SPINで行ったDPPのモデル検査に比べると,Gears Agdaの方がコードも長く、制約が多いため難解に思える。しかし,Gears Agda ではプログラムの実装も含んでいる。
198 198
199 さらに,Gears Agda での実装をしたあとのモデル検査を行う際の Meta Code Gear の流れは変化しないため,他のプログラムに適応できることを考えると比較的容易であると言える. 199 さらに,Gears Agda での実装をしたあとのモデル検査を行う際の Meta CodeGear の流れは変化しないため,他のプログラムに適応できることを考えると比較的容易であると言える。
200 200
201 加えて,Gears Agda は CbC へコンパイルされ,高速に実行されることを踏まえると,いかに Gears Agda が検証に向いたプログラムであるか理解できる. 201 加えて,Gears Agda は CbC へコンパイルされ,高速に実行されることを踏まえると,いかに Gears Agda が検証に向いたプログラムであるか理解できる。
202 202
203 % この評価の話はまとめでしたほうがいいかもね? 203 % この評価の話はまとめでしたほうがいいかもね?