Type-Based Analysis of Deadlock
for a Concurrent Calculus
with Interrupts
Kohei Suenaga (Univ. of Tokyo)
Naoki Kobayashi (Tohoku Univ.)
Why concurrency and
interrupts?
• Because they are inevitable for
verification of OS kernels
2015/10/1
ESOP 2007
2
Difficulties in programming with
concurrency and interrupts
• Tracking control flow
– Asynchronous jump to handlers may occur
WHENEVER allowed
• Debugging
– Both concurrency and interrupts cause
non-determinism
2015/10/1
ESOP 2007
3
Can the following program
deadlock?
(* Main function *)
let flush niclock =
let data = dequeue () in
while !data != NULL do
sync (niclock) {
(* write data to NIC *)
}
data := dequeue ()
done
2015/10/1
(* Interrupt handler *)
let recv flag niclock =
...
if flag then
flush niclock
...
ESOP 2007
4
Contribution
• Concurrent calculus with interrupts
• Type system for deadlock-freedom
analysis on the calculus
2015/10/1
ESOP 2007
5
Existing work
• [Chatterjee et al. I&C’04]
– Calculus with interrupts
× does not deal with concurrency
• [Kobayashi et al. ’97~,
Flanagan et al.’99~, ...]
– Type-based deadlock-freedom analysis
× does not deal with interrupts
2015/10/1
ESOP 2007
6
Main idea of verification
• Checking that locks are acquired in
a strict order even if interrupts occur
– using types and effects
Main program
x1:
x2:
a :
y2:
y1:
2015/10/1
Handler
sync (l1) {
sync (l2) {
print “me”;
}
}
X2:
X1:
A :
Y1:
Y2:
ESOP 2007
sync (l2) {
sync (l3) {
print “ME”;
}
}
7
Outline
•
•
•
•
Target language
Type system
Related work
Conclusion
2015/10/1
ESOP 2007
8
Syntax
M ::=
(M1 | M2)
(concurrent exec.)
let x = newlock () in M
(make new lock)
sync x in M
(synchronization)
M1 ▷ M2
(installing handler)
disable_int M
(disabling interrupts)
true | false | if M then M1 else M2 | …
2015/10/1
ESOP 2007
9
Handler installation
M1 ▷ M2
• M2 may start asynchronously if
interrupts are not disabled
– M2 does not yield voluntarily
• M1 resumes from the point M1 is
interrupted after M2 finishes
2015/10/1
ESOP 2007
10
Example of evaluation
(print “a”; print “b”)
▷ (print “c”; print “d”)
“a” is printed
(print “b”)
▷ (print “c”; print “d”)
(print “b”)
▷ (print “c”; print “d”)
2015/10/1
interrupt
resume
(print “c”; print “d”)
“c” and “d”
are printed
0
ESOP 2007
11
Disabling interrupts
disable_int M
• Interrupts are disabled during execution
of M
2015/10/1
ESOP 2007
12
Outline
•
•
•
•
Target language
Type system
Related work
Conclusion
2015/10/1
ESOP 2007
13
Design principle
behind the type system
• Checks that locks are acquired
in a certain order
– Deadlocks are caused by circular
dependency among locking operations
×
(sync x in sync y) | (sync y in sync x)
Do not agree on the order
between x and y
2015/10/1
ESOP 2007
14
Lock level
• A natural number associated with each
lock type
– Locks have to be acquired in a strict
increasing order of lock levels
2015/10/1
ESOP 2007
15
Example
x:lock(0), y:lock(1)
(sync x in sync y) | (sync x in sync y)
×
(sync x in sync y) | (sync y in sync x)
2015/10/1
ESOP 2007
16
Type judgment
G ├ M : t & (n1, n2)
min. of
lock levels
acquired
2015/10/1
max. of lock
levels while
interrupts are
allowed
ESOP 2007
17
Example
• Locking behavior of M ≡ sync x in sync y
– x:lock(1), y:lock(2)
level
unlock y
lock y
unlock x
lock x
2015/10/1
ESOP 2007
18
Example
• Suppose z is acquired before M
(i.e., sync z in M)
level
lock z
z must be less than all the locks
acquired in M
2015/10/1
ESOP 2007
19
Example
• Suppose M’ is installed as a handler
(i.e., M ▷ M’)
level
Locking behavior
of M’
All the locks acquired in M’ must be
greater than that in M
2015/10/1
ESOP 2007
20
Example
• Suppose interrupts are disabled in
a part of M (i.e., disable_int is in M)
level
Interrupts are
disabled here
“All the locks acquired in M’ is greater than
that in M while interrupts are enabled” is
sufficient
2015/10/1
ESOP 2007
21
Example
level
This range needs to be tracked
as an effect
Interrupts are
disabled here
2015/10/1
ESOP 2007
22
Effect
• Indicates locking behavior
(n1, n2)
min. of
lock levels
2015/10/1
max. of lock
levels while
interrupts are
allowed
ESOP 2007
23
Syntax of types
2015/10/1
ESOP 2007
24
Type judgment
G ├ M : t & (n1, n2)
Effect
• M acquires locks in a strict increasing
order of lock levels during an evaluation
• M acquires locks according to the effect
(n1, n2)
2015/10/1
ESOP 2007
25
Typing rule for sync
G, x:lock(n)├ M : t & (n1, n2)
n < n1
G, x:lock(n)├ sync x in M : t & (n, n2)
2015/10/1
ESOP 2007
26
Typing rule for interrupts
G├ M1: t & (n1, n2)
G├ M2: unit & (n1’, n2’)
n 2 < n 1’
G├ M1 ▷ M2 : t &
(min(n1,n1’), max(n2, n2’))
2015/10/1
ESOP 2007
27
Typing rule for disable_int
G├ M : t & (n1, n2)
G├ disable_int M : t & (n1, -∞)
2015/10/1
ESOP 2007
28
Type soundness
• If ├ M : t & (n1, n2) and M * M’
then M’ is not deadlocked
2015/10/1
ESOP 2007
29
Type inference
•
Constraint-based type inference
1. Constructs a derivation tree
2. Extracts constraints
•
•
Equalities between types
{t1 = t1’, t2 = t2’, ...}
Inequalities between lock levels
{n1 < n1’, ..., m1 ≤ m1’, ...}
3. Solves them
2015/10/1
ESOP 2007
30
Outline
•
•
•
•
Target language
Type system
Related work
Conclusion
2015/10/1
ESOP 2007
31
Related work
• [Chatterjee et al. I&C’04]
– Calculus with interrupts
– Guarantees that infinite-depth interrupt is
not possible
Does not deal with concurrency
2015/10/1
ESOP 2007
32
Related work
• [Kobayashi et al. ’97~, Flanagan et
al. ’99~]
– Type-based deadlock analyses
Do not deal with interrupts
2015/10/1
ESOP 2007
33
Conclusion
• Concurrent calculus with interrupts
• Type system for deadlock-freedom
verification on that calculus
– First framework equipped with both
concurrency and interrupts
2015/10/1
ESOP 2007
34
Ongoing work
• Extension for kernel verification
– Structures, arrays, pointer arithmetic,...
– Non block-structured synchronization
primitive
• Implementation of verifier
• Verification of more safety properties
– race-freedom, atomicity,...
2015/10/1
ESOP 2007
35
Fin
FAQ
あなたの言語はp計算で
エンコードできるのでは?
• 多分できると思います
– 但し、エンコードされたプログラムに対する
精度の高い検証ができるかどうかは疑問
2015/10/1
ESOP 2007
38
Block-structure でない
同期プリミティブはどう扱う?
• [Kobayashi et al. ’97~] のアイデアを
使えると思います
– ロックに対する acquire/release がどう起こ
るかを使用法表現として推論
• (lock, L.UL ▷ L.UL)
メイン処理で lock;unlock, 割り込みハンドラで
lock;unlock されるロックの型
– capability/obligation level で循環する
依存関係を排除
2015/10/1
ESOP 2007
39
Example of judgment
G = x:lock(1),
y:lock(2)
NG: lock x lock y
interrupt lock y violates
strictness of locking order
G├ sync x in sync y in 0 ▷ sync y in 0 : …
G├ sync x in disable_int(sync y in 0)
▷ sync y in 0 : int & ...
OK: Handler is not executed
while y is locked
2015/10/1
ESOP 2007
40
Effects
(n1, n2)
min. of
lock levels
2015/10/1
max. of lock
levels while
interrupts are
allowed
ESOP 2007
41
Property that should hold in
sync x in M
min. of levels of locks
level of x <
that may acquired in M
min. of levels should be in effects
2015/10/1
ESOP 2007
42
How about interrupts?
(sync x in sync y in 0)
▷ (sync z in 0)
2015/10/1
ESOP 2007
43
How about interrupts?
(sync x in sync y in 0)
▷ (sync z in 0)
max. of levels of x and y
< level of x
sync z ... may begin at any time during sync
x in sync y in 0
max. of levels should be in effects
2015/10/1
ESOP 2007
44
How about disable_int?
(sync x in disable_int(sync y in 0))
▷
(sync z in 0)
2015/10/1
ESOP 2007
45
How about disable_int?
(sync x in disable_int(sync y in 0))
▷
(sync z in 0)
max. of levels of x < level of x
sync z ... will not begin during sync y in 0
“max. of levels while interrupts are
enabled” is sufficient
2015/10/1
ESOP 2007
46
Type system
• Guarantees that locks are acquired in
a strict order even if interrupts occur
– Adds natural numbers (lock levels)
to lock types
– Tracks locking behavior using effects
2015/10/1
ESOP 2007
47
Examples
• Priority among interrupts
(main() ▷ low()) ▷ high()
low can interrupt
main
• high can interrupt main and low
• low cannot interrupt high
2015/10/1
ESOP 2007
48
Examples
• Dynamic change of handlers
Note that function names are firstChange of
class
f may interrupt M
handler (f to g)
g may interrupt M
let x = ref f in
( M ; x := g; M’ ) ▷ (!x)()
2015/10/1
ESOP 2007
49
予備
Outline
• Final aim: Verification of OS kernels
– OS kernels heavily use concurrency
and interrupts
• Current status:
– Calculus with concurrency
and interrupts
– Type system for deadlock-freedom
verification on the calculus
2015/10/1
ESOP 2007
51
OS 検証が重要な理由
• OS はコンピュータの基本中の基本！
– OS の異常即ちコンピュータの異常
• OS にバグがあると, アプリケーションを
検証しても無駄！
– ほとんどのプログラム検証手法は, OS と
ハードウェアの安全性を仮定
2015/10/1
ESOP 2007
52
Main idea of verification
• ロックに自然数による順序をつけて,
ロックがその順番で取得されることを型
スレッド 1
スレッド 2
で保証
x1:
x2:
a :
y2:
y1:
sync (l1) {
sync (l2) {
print “me”;
}
}
X1:
X2:
A :
Y2:
Y1:
sync (l1) {
sync (l2) {
print “ME”;
}
}
• このプログラムは OK
– どちらのプロセスも, l1 l2 という順序を守っている
2015/10/1
ESOP 2007
53
検証の基本的アイデア
• ロックに自然数による順序をつけて,
ロックがその順番で取得されることを型
スレッド 1
スレッド 2
で保証
x1:
x2:
a :
y2:
y1:
sync (l1) {
sync (l2) {
print “me”;
}
}
X2:
X1:
A :
Y1:
Y2:
sync (l2) {
sync (l1) {
print “ME”;
}
}
• このプログラムは NG
– l1 l2 と l2 l1 が混在
2015/10/1
ESOP 2007
54
Main idea of verification
• ロックに自然数による順序をつけて,
ロックがその順番で取得されることを型
スレッド 1
スレッド 2
で保証
x1:
x2:
a :
y2:
y1:
sync (l1) {
sync (l2) {
print “me”;
}
}
X1:
X2:
A :
Y2:
Y1:
sync (l1) {
sync (l2) {
print “ME”;
}
}
• このプログラムは OK
– どちらのプロセスも, l1 l2 という順序を守っている
2015/10/1
ESOP 2007
55
検証の基本的アイデア
• ロックに自然数による順序をつけて,
ロックがその順番で取得されることを型
スレッド 1
スレッド 2
で保証
x1:
x2:
a :
y2:
y1:
sync (l1) {
sync (l2) {
print “me”;
}
}
X2:
X1:
A :
Y1:
Y2:
sync (l2) {
sync (l1) {
print “ME”;
}
}
• このプログラムは NG
– l1 l2 と l2 l1 が混在
2015/10/1
ESOP 2007
56
Main idea of verification
• 割り込みが伴う場合も順序が守られる
割り込みを禁止
ことを保証する
メインのプログラム
割り込みハンドラ
x1:
x2:
a :
y2:
y1:
disable_int {
sync (l1) {
sync (l2) {
print “me”;
}
}
}
2015/10/1
X2:
X1:
A :
Y1:
Y2:
sync (l2) {
sync (l3) {
print “ME”;
}
}
• このプログラムは OK
– 割り込みが起こらないので l1 l2
ESOP 2007 l3 という順序が守られる 57
Examples
• Interrupts in multi-processor
(M1 ▷ h1()) | (M2 ▷ h2())
CPU1
CPU2
During CPU1 is in interrupt mode,
CPU2 is in normal mode
2015/10/1
ESOP 2007
58
What information should be
included in effects?
M 1 ▷ M2
max. of levels of locks < min. of levels of locks
that may acquired in M1
that may acquired in M2
max. of levels should be in effects
2015/10/1
ESOP 2007
59
Interrupts
• Mechanism to notify CPU that certain
events occur
– I/O completion, division by zero,...
• Cause asynchronous jump to interrupt
handlers
2015/10/1
ESOP 2007
60
Interrupt
handler
Main work
Interrupts!
Processes
interrupts
Resume
2015/10/1
ESOP 2007
61
Effect の例
• (1, 2)
– 取られうるロックのレベルは 1 以上
– 割り込みが許可されている間はレベル 2 以下
のロックしか取得されない
• (1, -inf)
– 取られうるロックのレベルは 1 以上
– 割り込みが許可されている間はロックが取得されない
• (inf, -inf)
– ロックは取得されない
2015/10/1
ESOP 2007
62
Example of judgment
G = lock(1), lock(2)
G├ sync x in sync y in 0 : int & (1, 2)
G├ (sync x in sync y in 0) |
(sync y in sync x in 0) : …
NG: y (level 2) is acquired
before x (level 1)
2015/10/1
ESOP 2007
63
型判定
G ├ M : t & (n1, n2)
• M の評価が停止すれば, その型は t
• M はその評価中に effect (n1, n2) に従って
ロックレベルの strict な昇順でロックを取得
2015/10/1
ESOP 2007
64
Type inference
• 型付け規則に基づいて導出木を
下から上に作る
– 型付け規則が syntax-directed なので,
この部分は自明
• ロックレベルに関する制約を集める
– n < n’, n ≤ n’, n = n’ のいずれかの形
• 制約を満たすロックレベルの代入が存在するか
どうかを調べる
– 不等式を解く問題に帰着
2015/10/1
ESOP 2007
65
How about interrupts?
• What should n below satisfy?
Main program
Handler
locks level 1
locks level n
...
locks level 2
locks level 3
2015/10/1
ESOP 2007
66
How about interrupts?
• What should n below satisfy?
Main program
Handler
locks level 1
locks level n
...
locks level 2
locks level 3
2015/10/1
The handler may begin
at any time
ESOP 2007
67
How about
disabling interrupts?
• What should n below satisfy?
Main program
Handler
locks level 1
locks level n
...
locks level 2
locks level 3
2015/10/1
ESOP 2007
68
Syntax
P (program) ::= D1, ..., Dn, M
D (def. of func.) ::= f (x1,...,xn) = M
M ::=
[standard first-order language]
| (M1 | M2)
(concurrent exec.)
| let x = newlock () in M
(make new lock)
| sync x in M
(synchronization)
| M1 ▷ M2
(installing handler)
| disable_int M
(disabling interrupts)
2015/10/1
ESOP 2007
69
Related work
• Asynchronous exceptions
[Gosling et al. 2005,
Marlow et al. PLDI2001]
– Exceptions risen asynchronously
• 非同期的にハンドラに制御が移りうる点で
本研究と関係
– ハンドラからの復帰は扱っていないので,
割り込みとは異なる
2015/10/1
ESOP 2007
70
Outline
• 対象言語 & プログラム例
• 型システム
–
–
–
–
型の syntax
型判定
型付け規則
型推論
• 関連研究
• まとめ
• race-freedom 検証の進捗状況
2015/10/1
ESOP 2007
71
Race condition とは
• 一つの reference にアクセスしようとして
いるスレッドが二つ以上あって, そのうち少
なくとも一つが書き込みであること
– (x := 1) | (x := 2) race
– (x := 1) | (print (!x)) race
– (print (!x)) | (print (!x)) not race
2015/10/1
ESOP 2007
72
Race-freedom 検証の idea
• Resource usage analysis
[Kobayashi&Igarashi TOPLAS2005]
の利用
– reference や lock に対してどのような
アクセスが行われるか (usage) を
型システムで抽出
– 抽出された usage が race 状態に至らないこ
とをモデル検査で検証
2015/10/1
ESOP 2007
73
アルゴリズムの動作例
(型推論フェーズ)
let y = newlock () in let x = ref 0 in
(sync y in print !x)
| (sync y in x := 0) ▷ (print !x)
型推論器
Usage of x =
(sync y in xW)
| (sync y in xW) ▷ xR
2015/10/1
ESOP 2007
74
アルゴリズムの動作例
(モデル検査フェーズ)
(sync y in xW)
| (sync y in xW) ▷ xR
モデル検査器
xW | xR に至るパスが
存在するのでエラー
この usage から race に
相当する状態に至る
パスがあるか?
2015/10/1
ESOP 2007
75
Usage の syntax
引数は呼び出し後 U1 に従って使用され,
返り値は return 後 U2 に従って使用される関数
t ::= unit | int | bool | t ref | lock
| (x1:t1,...,xn:tn)U1 (r:t)U2
U ::= 0 | a | xR | xW | U1;U2 | (U1 | U2)
| (U1 & U2) | rec a. U | sync x in U
| U1 ▷ U2 | disable_int U | ◊U
今後どこかで U に従って使われる
値の usage
2015/10/1
ESOP 2007
76
型判定
(G)U1 ├ M : (r:t)U2
• M の評価中に G 中の変数が束縛されている値は U1
に従って使われる
• M の評価結果の型は t で, その値は M の評価が終
わったあと U2 に従って使われる
– 但し, U2 中では評価結果の値を r で表す
• M の評価中に race condition が起こることはない
2015/10/1
ESOP 2007
77
型判定の例
G1 = x : ref, f : (z:ref)zR ...
G2 = x : ref, y : lock,
f : (z:ref, w:lock)sync w in zR ...
(G1) (xR ▷ xW) | xR├ (f x ▷ x := 1) | f x : ...
(G2) (sync y in xR ▷ xW) | sync y in xR)├
(f (x, y) ▷ x := 1) | f (x, y)) : ...
(G2) (sync y in xR ▷ sync y in xW) |
sync y in xR)├
(f (x, y) ▷ sync y in x := 1) | f (x, y)) : ...
2015/10/1
ESOP 2007
78
現状での問題点
• ref への ref や lock への ref が扱えな
い
– ref!xのinaliasing
sync
(!r := 1)に関する情報がないため
| sync !y in (!s := 1)
• x と y が alias しないかもしれないなら
r と s が alias するかもしれないときに
race
2015/10/1
ESOP 2007
79
現状の問題点
• モデル検査アルゴリズムを考えていない
– 割り込みを考慮したアルゴリズムが必要
2015/10/1
ESOP 2007
80
Fin
復習: 並行プログラム
• 複数の処理が同時に実行される
プログラムのこと
– 状態数が指数的に増えるので, 検証は逐次
プログラムと比べて大変
2015/10/1
ESOP 2007
82
この 2 つのプロセスが
同時に走ったら?
a: t1 = x;
b: t1 = t1 + 1
c: x = t1;
A: t2 = x;
B: t2 = t2 - 1;
C: x = t2;
• 可能な実行経路は abcABC, abAcBC,...
の20 通り
– 状態数が大きくて大変そうでしょ
• 実行後の x の値は -1, 0, 1 のいずれか
2015/10/1
ESOP 2007
83
復習: ロック
• 複数のプロセスの “待ち合い” に使われる
オブジェクト
– 取得と解放の二つの操作が可能
– 既に誰かが取得していたロックを取得しようと
した場合, ロックが解放されるまで待たされる
2015/10/1
ESOP 2007
84
ロックの使用例
x: sync (l) {
a: t1 = x;
b: t1 = t1 + 1
c: x = t1;
y: }
X: sync (l) {
A: t2 = x;
B: t2 = t2 - 1;
C: x = t2;
Y: }
• 可能な実行経路は xabcyXABCY か
XABCYxabcy の 2 通りに
– xX... とか Xx... とかはありえない
• 実行後の可能な x の値は 0 のみ
2015/10/1
ESOP 2007
85
復習: デッドロック
• いくつかのプロセスが互いにロックを待
ちあって, 実行が進まない状態
x1:
x2:
a :
y2:
y1:
sync (l1) {
sync (l2) {
print “me”
}
}
X2:
X1:
A :
Y1:
Y2:
sync (l2) {
sync (l1) {
print “ME”;
}
}
• x1, X2 と実行が進んだ時点でデッドロック
– x2 も X1 も実行できない
2015/10/1
ESOP 2007
86
Syntax of types
n (lock level) ∈ {0, 1, ...} ∪ {-inf, inf}
t ::= unit | int | bool | t ref
| lock(n)
| (t1,...,tm);(n1, n2) t
latent effect
2015/10/1
ESOP 2007
87
Type-Based Analysis of Deadlock
for a Concurrent Calculus
with Interrupts
Kohei Suenaga (Univ. of Tokyo)
Naoki Kobayashi (Tohoku Univ.)
Effect
• Indicates locking behavior
(n1, n2)
min. of
lock levels
acquired
2015/10/1
max. of lock
levels while
interrupts are
allowed
ESOP 2007
89
© Copyright 2024 ExpyDoc
