Date post: | 15-Dec-2015 |
Category: |
Documents |
Upload: | audrey-read |
View: | 214 times |
Download: | 1 times |
REVIEW
Parallel and distributed systems Validation of systems are difficult “Model checking tools”
Check models of them mechanically
2
Initial state
State transition
Assertion
SPIN MODEL CHECKER AND PROMELA
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
MODEL 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
msg
ack
ack
ReceiverSender
THE STRUCTURE OF PROMELA 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
PROCESSES (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: 0my pid is : 1
2 processes created
2 processes are defined
Each of them is executed
simultaneously 7
PROCESSES (2)
Another expression to run processes
8
proctype you_run(){printf("my pid is: %d\n",
_pid)}
init{run you_run();run you_run();
}
my pid is: 2 my pid is: 13 processes created
Process definition without “active”
DATA 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
chan Message channels mtype Message types pid Process id
Scope of variables Global Process local
No function exists in Promela
User-defined types are available
Type Typical Range
bit 0, 1
bool false(0), true(¬0)
byte 0 .. 255
chan 1 .. 255
mtype 1 .. 255
pid 0 .. 255
short -215 .. 215 - 1
int -231 .. 231 - 1
unsigned
0 .. 2n - 1
9
typedef Field{short f =
3;byte g
}
DATA OBJECTS (2)
mtype Variable type for labeling of kinds of messages Similar to “enum” in C
10
mtype = {msg, ack};
MESSAGE 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,var3qnam
e
MESSAGE 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”
MODEL 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
msg
ack
ack
ReceiverSender
EXECUTABILITY
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
SELECTIONS (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
SELECTIONS (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
REPETITIONS
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
ATOMIC SEQUENCES ANDDETERMINISTIC 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;}
ESCAPE 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}
SUMMERY
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
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
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
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
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
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
Examples
Dijkstra’s Semaphore (Model)
Count
User Processes
Semaphore
User1 User2 User3 …
P operation
If(count !=0)
Count --
V operation
Count ++
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 }
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.
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
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
Never Claims Another Expression
never{
do
:: assert (p)
od
}
active proctype monitor() {
atomic{ !p -> assert ( false)}
}
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)
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
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.
Predefined Variables and Functions
Predefined Functions pc_value(pid)
enabled(pid)
proctype[pid]@label
proctype[pid]: var (Remote Refernce, only SPIN 4.0 or later)
Logical Formulation using LTL
LTL is a modal temporal logic with modalities referring to time.
One can formulate logical condition and its temporal changes
Symbol Explanation
¬,∧,∨,→
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 q q remains true until p becomes true (Until)
X p p has to become true at the next state (neXt)
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)) ’
SPIN STRUCTURE
44
Syntax checker Promelaで記述したモデルの文法をチェックする
Simulatorランダムまたは指定のシーケンスで実行を行う
Verifier generator検証器のコードを生成する検証器は状態空間探索によってモデルの正当性を検証する
ROADMAP
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
RANDOM SIMULATION (1)ランダムシミュレーション
$ spin model -nN 乱数の種を Nに指定
いろいろと情報を出力する $ spin -p -l -g model
-p 全ての文の実行履歴を出力 -l 状態変化したプロセスのローカル変数を出力 -g グローバル変数の変化を出力
範囲を指定 $ spin -jN -uM model
Nステップから出力し、Mステップまでで打ち切る 47
RANDOM SIMULATION (2)チャネルによるメッセージの通信イベントを出力
$ spin -s -r model -s 送信イベント -r 受信イベント
$ spin -c model送受信イベントをプロセスごとにカラム表示
48
GENERATING A VERIFIER検証器のコードを生成
$ spin -a model pan.b pan.c pan.h pan.m pan.l ができる
メッセージが失われるモデル $ spin -a -m model
-m チャネルキューが一杯のときメッセージを破棄
51
COMPILING 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
BITSTATE VERIFICATION
普通は 1状態の表現に数十~数百バイト必要大きな探索空間ではメモリがあふれる
状態空間をビットで表現メモリ消費量を格段に削減するただし探索の完全性は保証されない状態数の 100倍以上のメモリがあれば 99%以上のカバー率
53
TUNING A VERIFICATION RUN
普通に検証を実行 $ ./pan
ハッシュテーブルサイズを調整 $ ./pan -wN
2^N個の状態を扱える小さすぎると探索時間大。大きすぎるとメモリ消費大。どちらでも探索の結果に影響はない
ただし、ビット状態空間のときは、小さいとカバー率低下サイズを増やしながら繰り返すのが効率的
54
SEARCH DEPTH (1)
探索の深さを調整 $ ./pan -mNデフォルトは N=10,000大きな状態空間を全探索したいときは深く浅いステップのエラーを見つけるときは浅く
探索スタックをディスクにスワップ $ gcc -DSC -o pan pan.c $ ./pan -mN Nステップまではメモリ、それ以降はディスク
55
SEARCH DEPTH (2)
深さ N以内で最短のエラーシーケンスを見つけたい $ gcc -DREACH -o pan pan.c $ ./pan -i -mNビット状態空間は完全性を欠くため使えない
幅優先探索 $ gcc -DBFS -o pan pan.c無限ループではなく、デッドロックや assert違反など、一瞬のエラー状態のみを見つけるとき
56
ERROR
そもそもエラーとは
Safety propertyデッドロック (invalid end states) assert違反
Liveness property Acceptance cycle
特定の状態を通過する無限ループ Non-progress cycle
特定の状態を通過しない無限ループ57
LIVENESS PROPERTY
Acceptance cyclesを検出 $ ./pan -a
Non-progress cyclesを検出 $ gcc -DNP -o pan pan.c $ ./pan -l
59
INSPECTING ERROR TRACES
Guided simulationエラーを起こすシーケンスを再現する $ spin -t -p model
N個目のエラーだけを検出 $ ./pan -cN
N=0だとエラーが出ても探索を継続する
60