社内勉強会のスライド

1. SPIN で
Critical Section のアルゴリズム
を検証する
@giantneco

2. ソースコード
https://github.com/giantneco/spin-dekker.git

3. motivation
● SPIN覚えたので使ってみよう
● 次の本を参考にしています
– 並行コンピューティング技法 [Clay Breshears]

4. 結論
● あんまりうまく使えませんでした
– 反省点にまとめてあります

5. Critical Section 問題
● 同時にアクセスがあると破綻する共有変数をどのように扱うか？
● 問題の解決するアルゴリズムには次の性質が必須：
– (性質１ 排他制御) 他のスレッドがクリティカルセクションへ入る事は
禁止される。複数の平行な要求がある場合にクリティカルセクションに
入る事ができるスレッドは一つだけである
– (性質２ 同時実行)スレッドがクリティカルセクション外で実行中なら
ば、そのスレッドは他のスレッドがクリティカルセクションに入る事を
妨げてはならない
● 必須ではないが…
– 公平性も検査してみる
– デッドロックも検査する

6. 検証対象のアルゴリズム
● Critical Section を実現するアルゴリズム
– Dekker 's algorithm
● 簡略化のため２スレッドのみのアルゴリズム
– Dekker's algorithm のプロトタイプ
● 何もしない
● 排他制御のみ
● 排他制御 + 同時実行 (1)
● 排他制御 + 同時実行 (2)

7. 検証の方針
● 性質は LTL 式で表し Never Claim に与える
● 他に以下の性質も確認
– デッドロック → never claim 無しで実行

8. とりあえず LTL (1)
● 以下の述語を用意 (common.pml)
– in{1,2}
● スレッドNがクリティカルセクション内にいる
– out{1,2}
● スレッドNがクリティカルセクション内でなく、ロック
していない
– lock{1,2}
● スレッドNがロックしている

9. LTL (ii)
● 排他制御
– □ !( in1 && in2 )
● 常に、同時にCSに入ることはない
● 同時実行
– □ ( out2 && X out2 → X ! lock1 )
● 常に、スレッド2がある時点とその次のステップで CS に入っていないなら、その次の
ステップでスレッド1はロックされていない
● これはうまくいかなかった
● 公平性
– □◇ in1
● 常に、いつかCSに入る
● 対象な構造をしているのでどちらか片方のスレッドで十分
● 常にCSに入る可能性がある状態のはずなので、仮定はいれていない

10. アルゴリズム 0
● nolock/main.pml
● 特になにも工夫はしていない
– いわゆるノーガード戦法
● 排他制御の LTL が働く事を確認したい

11. アルゴリズム 0 結果
● デッドロックしないか？
– ○ → ロックしていないため
● 排他制御
– × → 排他制御していない
● 同時実行
– ○
● 公平性
– ○

12. アルゴリズム 1
● prototype1/main.pml
● 排他制御だけ実現するアルゴリズム
– 一つの共有変数でCSに入れるスレッドを決める
– 二つのスレッドが交互に動作する
– 当然、同時実行はしない

13. アルゴリズム 1 結果
● デッドロックしないか？
– ○
● 排他制御
– ○
● 同時実行
– ×
● 公平性
– ○

14. アルゴリズム 2
● prototype2/main.pml
● 排他制御 + 同時実行
– 二つの共有変数でCSに入っているスレッドがわか
る
– 他のスレッドが出るのを待ってから入る

15. アルゴリズム 2 結果
● デッドロックしないか？
– ▲ (弱公平性の仮定が必要)
● 本来×になるはずだった…
● 排他制御
– ×
● 同時実行
– ×
● 公平性
– × → ちょっとおかしい？

16. アルゴリズム 3
● prototype3/main.pml
● 排他制御 + 同時実行
– 二つの共有変数でCSに入ろうとしているスレッド
がわかる
– 先に入ろうとしているスレッドがあれば、そのス
レッドが出るのを待ってから入る

17. アルゴリズム 3 結果
● デッドロックしないか？
– ▲ (弱公平性の仮定が必要)
● 本来×になるはずだった…
● 排他制御
– ○
● 同時実行
– ×
● 公平性
– ○

18. Dekker's Algorithm
● dekker/main.pml
● 排他制御 + 同時実行
– 二つの共有変数でCSに入ろうとしているスレッド
がわかる
– 一つの共有変数でどのスレッドが優先的にCSに入
れるかわかる
– 先に入ろうとしているスレッドがある場合、優先
度の高いスレッドが入る

19. Dekker's Algorithm 結果
● デッドロックしないか？
– ▲ (弱公平性の仮定が必要)
● ○になって欲しかった
● 排他制御
– ○
● 同時実行
– ×
● 本来○になるはずだった…
● 公平性
– ○

20. 以下、反省点

21. 同時実行の LTL 式
● LTL 式が難しい
● □ (スレッド1がクリティカルセクションに入
る条件を満たしていない かつ スレッド2がク
リティカルセクションに入る条件を満たして
いる → X スレッド２がクリティカルセクショ
ンに入る)
– これは LTL 式にかける？
– X だけで済む？

22. 弱公平性の仮定
● この仮定をいれるとどのアルゴリズムもデッ
ドロックしないと判定されてしまった
– 他の公平性を試すべきだったかも

23. LTL 式の書きかた
● LTL 式
– o2 && X o2 → X ! l1
● この LTL 式を never claim にして実行
– 状態遷移の探索が途中でとまってしまった！
– □、◇がない場合は探索が途中でとまる

24. Promela で表現できなかったもの
● 乱数時間だけスリープ
– DO :: skip :: break; OD でいけるかと思ったがエ
ラーになった

25. 感想
● Good!
– 簡単なモデルだったら使える
● 実際、prototype2 までは検証はうまく行った
● Bad
– 複雑になると途端に難しくなる
– 情報が少ない…

26. 参考文献
● 「並行コンピューティング技法」
– Cray Breshears
– 千住治郎 訳
● 「SPINによる設計モデル検証」
– 萩谷昌己 監修
– 吉岡信和・青木利晃・田原康之 共著

27. 発表後にもらったコメント
● SPIN と LTL の Next Operator の相性は悪い
– SPINは並列動作をインタリーブしてシミュレー
ションする
– 「次の状態」が厳密に決められない場合がある
● LTL を使う場合は有用なパターンがあるので
それを使用するのが良い
– Absence pattern : □ ! p