Presentation is loading. Please wait.

Presentation is loading. Please wait.

T HE S PIN M ODEL C HECKER [H OLZMANN, 03] C HAPTER 3, 4, AND 11 Takumi Kida Mitsuharu Kurita Ayato Miki 1.

Similar presentations

Presentation on theme: "T HE S PIN M ODEL C HECKER [H OLZMANN, 03] C HAPTER 3, 4, AND 11 Takumi Kida Mitsuharu Kurita Ayato Miki 1."— Presentation transcript:

1 T HE S PIN M ODEL C HECKER [H OLZMANN, 03] C HAPTER 3, 4, AND 11 Takumi Kida Mitsuharu Kurita Ayato Miki 1

2 R EVIEW Parallel and distributed systems Validation of systems are difficult “Model checking tools” Check models of them mechanically 2 Initial state State transition Assertion

3 C HAPTER 3 A N O VERVIEW OF P ROMELA Mitsuharu Kurita 3

4 S PIN MODEL CHECKER AND P ROMELA Spin Model checker for parallel / distributed systems Validate the state transition of models Modeling language: Promela Promela Modeling language with C-like syntax Not intended to be used in implementation 4 active proctype Sender(){ again: to_rcvr!msg; to_sndr?ack; goto again } ……………. active proctype Sender(){ again: to_rcvr!msg; to_sndr?ack; goto again } ……………. Promela codeSystem model

5 M ODEL EXAMPLE 1 Primitive sender / receiver 5 mtype = {msg, ack}; chan to_sndr = [2] of {mtype}; chan to_rcvr = [2] of {mtype}; active proctype Sender(){ again:to_rcvr!msg; to_sndr?ack; goto again } active proctype Receiver(){ again:to_rcvr?msg; to_sndr!ack; goto again } msg ack ReceiverSender

6 T HE STRUCTURE OF P ROMELA CODE 3 main components in Promera mtype = {msg, ack}; chan to_sndr = [2] of {mtype}; chan to_rcvr = [2] of {mtype}; active proctype Sender(){ again:to_rcvr!msg; to_sndr?ack; goto again } active proctype Receiver(){ again:to_rcvr?msg; to_sndr!ack; goto again } 6 Processes Message channels Data objects

7 P ROCESSES (1) Multiple processes which work in parallel Different from “native” processes Expressed as objects of “proctype” type Process details are written like functions in C Up to 255 processes can be exist at the same moment active [2] proctype you_run(){ printf("my pid is: %d\n", _pid) } my pid is: 0 my pid is : 1 2 processes created 2 processes are defined Each of them is executed simultaneously 7

8 P ROCESSES (2) Another expression to run processes 8 proctype you_run(){ printf("my pid is: %d\n", _pid) } init{ run you_run(); } my pid is: 2 my pid is: 1 3 processes created Process definition without “active”

9 D ATA OBJECTS (1) Basic data types Basically they are derived from C All of them can be used as int Some do not exist in C chanMessage channels mtypeMessage types pidProcess id Scope of variables Global Process local No function exists in Promela User-defined types are available TypeTypical Range bit0, 1 boolfalse(0), true(¬0) byte chan mtype pid short int unsigned0.. 2 n typedef Field{ short f = 3; byte g }

10 D ATA OBJECTS (2) mtype Variable type for labeling of kinds of messages Similar to “enum” in C 10 mtype = {msg, ack};

11 M ESSAGE CHANNELS (1) Message channels Interprocess communications which have buffer Message has some fields expressed as data types User-defined types can be included 11 chan qname = [16] of {short, byte, bool} qname!10,50,true qname?var1,var2,var3 qname

12 M ESSAGE CHANNELS (2) Restricted reception You can restrict receiving messages with constant value 12 qname?30,var2,var3 Messages whose value of the first field is 30 can be received qname?eval(var1),var2,var3 Restriction with contents of variable “var1”

13 M ODEL EXAMPLE 1 ( REVISITED ) Primitive sender / receiver 13 mtype = {msg, ack}; chan to_sndr = [2] of {mtype}; chan to_rcvr = [2] of {mtype}; active proctype Sender(){ again:to_rcvr!msg; to_sndr?ack; goto again } active proctype Receiver(){ again:to_rcvr?msg; to_sndr!ack; goto again } msg ack ReceiverSender

14 C ONTROL FLOW Selections Repetitions Atomic sequences Deterministic steps Escape sequences 14

15 E XECUTABILITY Each expression in Promela has “executability” Processes block at “inexecutable” expression Basically it is boolean values of expressions Example: a == b : blocks until a == b (same as while(a != b){} in C) chan!val1 / chan?var1 : blocks if chan is full / empty false : eternally blocks a = b, printf : always executable 15

16 S ELECTIONS (1) Statements between “if” and “fi” Different from “if” block in C Each option is marked with “::” A statement whose first expression is executable is selected If more than 2 options are executable, one of them is chosen randomly 16 if :: (a != b) -> option 1 :: (a == b) -> option 2 :: printf(“Hello, world.”) fi printf can be executed regardless of values of a or b

17 S ELECTIONS (2) If all options are inexecutable, the process blocks until one or more options get executable Options can include “else”, which is executed only when all of the other options are inexcutable 17

18 R EPETITIONS Statements between “do” and “od” It repeats selection same as “if” repeatedly There is no “while” or “for” in Promela Simple loops are denoted by “goto” 18 do :: count++ :: count— od count randomly moves up and down

19 A TOMIC SEQUENCES AND D ETERMINISTIC STEPS Atomic sequences Statements in “atomic{}” Executed atomically as long as the statements are executable Deterministic steps Statements in “d_step{}” Each statement must be executable and deterministic Cannot get into / out of block with “goto” 19 atomic{ tmp = b; b = a; a = tmp; } d_step{ tmp = b; b = a; a = tmp; }

20 E SCAPE SEQUENCES 2 code blocks connected by “until” If the first statement in E is inexecutable, P is executed As soon as E gets exutable, E is executed and the control flow never backs to P If P is finished before E becomes executable, E is abandoned 20 {P}until{E}

21 M ODEL EXAMPLE 2 Simple model of telephone system 21

22 S UMMERY Introduced Promela Model definition language for Spin Syntax and functions of Promela 3 main components Data objects Message channels Processes Control flow Executability Selection Repetition and so on 22

23 Chapter 4 Takumi Kida

24 Outline of Chapter 4 About SPIN verification process Basic Types of Claims Basic Assertions End State Labels Progress State Labels Accept State Labels Never Claims Trace Assertions Built-in Variables and Functions Logical Formulations of Correctness LTL (Linear Temporal Logic) The Link between LTL and Never Claims

25 About SPIN verification process User can define some correctness requirement in PROMELA Some types of properties, such as system deadlock states, need not be stated explicitly. They are checked by default. SPIN does not care about {……}{……} META labels, assertion claims PROMALA Code Verifier

26 Basic Assertions Basic assertions are always executable The implied correctness property is that it is never possible for the expression to evaluate to false (or zero) Init{ assert ( expression ) /* assert that expression is true */ } Init{ assert ( false ) /* error */ } Examples

27 End State Labels In PROMELA, by default, the only valid end states are those in which every process has reached the end of its code The end state labels define additional valid end states Every labels name that starts with the prefix ‘end’ means end state label …(){ end: … } End of code is default end state Additional end state defined by user

28 Progress State labels Progress state labels is signifying that the executing process is making effective progress, rather than Every potentially infinite execution cycle passes through at least one progress labels. If cycles that do not have this property, it will be error of the existence of non-progress cycle Variation with a prefix ‘progress’ is available

29 Examples Dijkstra’s Semaphore (Model) Count User Processes Semaphore User1User2User3 … P operation If(count !=0) Count -- V operation Count ++

30 Examples Dijkstra’s Semaphore (Code) mtype {p,v}; chan sema = [0] of {mtype}; active proctype Dijkstra(){/*Semaphore Process*/ byte count=1; end: do/*this line is also valid end state !*/ :: (count == 1) -> progress: sema!p; count =0; :: (count == 0) -> sema?v; count =1; od } active[3] proctype user(){ do :: sema?p;/*Enter*/ critical:skip;/* Critical Section */ sema!v;/*Leave*/ od }

31 An example of non-progress cycle byte x =2;/*global */ active proctype A(){ do :: x = 3 - x; od } active proctype B(){ do :: x = 3 - x; od } /*x changes between 2 and 1 infiitely*/ If there is no progerss labels, these cycles is guaranteed to be a non-progress cycle.

32 Accept State labels The implicit correctness expressed by accept labels is that there should not be any infinite loops that pass through an accept state label. Accept state labels is normally used in never claims (next section) Variations with the prefix ‘accept’ is also available never{ accept: do :: !q/* q must not be false infinitely (eventually becomes true ) */ od; } Examples

33 Never Claims Never claim is normally used to specify either finite or infinite system behavior that should never occur Never claim checks system properties just before and just after each statement execution never{/* p must remain true */ do :: !p -> break /* break from never claim means error */ :: else od } Example

34 Never Claims Another Expression never{ do ::assert (p) od } active proctype monitor() { atomic{ !p -> assert ( false)} }

35 Never Claim as a State Machine ERROR S1 S0 never{ S0: do :: (p || !q ) -> break :: ture od S1: do accept:: !q :: ! (p || q) -> break od } true !( p || q) !q (p || !q)

36 Trace Assertions Trace assertion expresses a correctness requirement on the properties of message channels Trace assertion formalizes statements about valid or invalid sequences of operations that processes can perform on message channels A trace assertion monitors only a subset of the events in a system that are mentioned in the trace clause trace{ do :: q1!a; q2?b od } Examples

37 Predefined Variables and Functions Predefined Variables _ _ refers to a global, predefined, write-only, integer variable that can be used to store scratch values. _pid read-only variable of type pid that stores the instantiation number of the executing process. np_ read-only variable of type boolean that becomes true when system states are marked as non-progress states _last _last is a predefined global variable that holds the instantiation number of the process that performed the last step in the current execution sequence.

38 Predefined Variables and Functions Predefined Functions pc_value(pid) enabled(pid) proctype[pid]: var (Remote Refernce, only SPIN 4.0 or later)

39 Logical Formulation using LTL LTL is a modal temporal logic with modalities referring to time. One can formulate logical condition and its temporal changes SymbolExplanation ¬,∧,∨, → the usual logical connectives [ ] p p must be true on the entire subsequent path (Globally) <> p p eventually has to become true (Eventually) p U qq remains true until p becomes true (Until) X p p has to become true at the next state (neXt)

40 Formulation by LTL ERROR S1 S0 true !( p || q) !q (p || !q) ¬ [ ] ( p → (p U q) )

41 The Link between LTL and Never Claims In SPIN, there is an automatic generation tool of never claims using LTL ![ ] (p -> (p U q)) never { T0_init: if :: ( ( !(q) ) && (p)) -> goto accept_S4 :: ( true ) -> goto T0_init fi; accept_S4: if :: ( ! (q)) -> goto accept_S4 :: ( !(p) && !(q) ) -> goto accept_all fi; accept_all: skip } spin – f ‘ ![ ](p-> (p U q)) ’

42 Summery

43 C HAPTER 11 USING SPIN Ayato Miki 43

44 S PIN STRUCTURE 44 Syntax checker Promela で記述したモデルの文法をチェックする Simulator ランダムまたは指定のシーケンスで実行を行う Verifier generator 検証器のコードを生成する 検証器は状態空間探索によってモデルの正当性を検証す る

45 R OADMAP Syntax check $ spin -A model Random simulation $ spin model Verification $ spin -a model $ gcc -o pan pan.c $./pan Inspecting error traces $ spin -t -p model 45

46 S YNTAX CHECK モデルの文法をチェックする $ spin -A model 46

47 R ANDOM SIMULATION (1) ランダムシミュレーション $ spin model -nN 乱数の種を N に指定 いろいろと情報を出力する $ spin -p -l -g model -p 全ての文の実行履歴を出力 -l 状態変化したプロセスのローカル変数を出力 -g グローバル変数の変化を出力 範囲を指定 $ spin -jN -uM model N ステップから出力し、 M ステップまでで打ち切る 47

48 R ANDOM SIMULATION (2) チャネルによるメッセージの通信イベントを出力 $ spin -s -r model -s 送信イベント -r 受信イベント $ spin -c model 送受信イベントをプロセスごとにカラム表示 48

49 I NTERACTIVE SIMULATION 実行するシーケンスを手動で選択 $ spin -i -p model 49

50 G UIDED SIMULATION 検証の後で、エラーになったシーケンスを再現す る 50

51 G ENERATING A VERIFIER 検証器のコードを生成 $ spin -a model pan.b pan.c pan.h pan.m pan.l ができる メッセージが失われるモデル $ spin -a -m model -m チャネルキューが一杯のときメッセージを破棄 51

52 C OMPILING THE VERIFIER 検証器をコンパイル $ gcc -o pan pan.c 物理メモリの限度を MB 単位で指定 $ gcc -DMEMLIM=512 -o pan pan.c 使用メモリを節約するオプション群 $ gcc -DCOLLAPSE -o pan pan.c $ gcc -DHC4 -o pan pan.c $ gcc -DBITSTATE -o pan pan.c 52

53 B ITSTATE VERIFICATION 普通は 1 状態の表現に数十~数百バイト必要 大きな探索空間ではメモリがあふれる 状態空間をビットで表現 メモリ消費量を格段に削減する ただし探索の完全性は保証されない 状態数の 100 倍以上のメモリがあれば 99 %以上のカバー 率 53

54 T UNING A VERIFICATION RUN 普通に検証を実行 $./pan ハッシュテーブルサイズを調整 $./pan -wN 2^N 個の状態を扱える 小さすぎると探索時間大。大きすぎるとメモリ消費大。 どちらでも探索の結果に影響はない ただし、ビット状態空間のときは、小さいとカバー率低下 サイズを増やしながら繰り返すのが効率的 54

55 S EARCH DEPTH (1) 探索の深さを調整 $./pan -mN デフォルトは N=10,000 大きな状態空間を全探索したいときは深く 浅いステップのエラーを見つけるときは浅く 探索スタックをディスクにスワップ $ gcc -DSC -o pan pan.c $./pan -mN N ステップまではメモリ、それ以降はディスク 55

56 S EARCH DEPTH (2) 深さ N 以内で最短のエラーシーケンスを見つけたい $ gcc -DREACH -o pan pan.c $./pan -i -mN ビット状態空間は完全性を欠くため使えない 幅優先探索 $ gcc -DBFS -o pan pan.c 無限ループではなく、デッドロックや assert 違反など、 一瞬のエラー状態のみを見つけるとき 56

57 E RROR そもそもエラーとは Safety property デッドロック (invalid end states) assert 違反 Liveness property Acceptance cycle 特定の状態を通過する無限ループ Non-progress cycle 特定の状態を通過しない無限ループ 57

58 S AFETY PROPERTY 普通はこちらだけを検出 Assert 違反を検出しない $./pan -A Invalid end states を検出しない $./pan -E 58

59 L IVENESS PROPERTY Acceptance cycles を検出 $./pan -a Non-progress cycles を検出 $ gcc -DNP -o pan pan.c $./pan -l 59

60 I NSPECTING ERROR TRACES Guided simulation エラーを起こすシーケンスを再現する $ spin -t -p model N 個目のエラーだけを検出 $./pan -cN N=0 だとエラーが出ても探索を継続する 60


Download ppt "T HE S PIN M ODEL C HECKER [H OLZMANN, 03] C HAPTER 3, 4, AND 11 Takumi Kida Mitsuharu Kurita Ayato Miki 1."

Similar presentations

Ads by Google