Resource Usage Analysis for the Pi-Calculus

1
Resource Usage Analysis for the Pi-Calculus

• Naoki Kobayashi (Tohoku University)
• Kohei Suenaga (University of Tokyo)
• Lucian Wischik (Microsoft)

2
External Resources and Safety

• External resources should be accessed in a
  certain manner
• File (read write) close
• Memory (read write) deallocate
• Violating those protocols can cause harmful result

3
Resource Usage Analysis

• Statically check whether a program correctly
  accesses resources
• Extensively studied for sequential programs
• Type-based analysis IgarashiKobayashi
  TOPLAS05 etc.
• Model checking SLAM project etc.
• Only a few studies for concurrent programs
• esp. those creating resources and channels
  dynamically

4
Our Aim

• Resource usage analysis for concurrent programs
  with dynamic creation of resources and channels

5
Checked Properties

• Safety
• Program does not perform illegal accesses
• Programs should not access closed files
• Programs should not access deallocated memory
• Partial liveness
• All the required accesses are performed unless
  program diverges
• Programs should eventually close opened files

6
Syntax of Target Language
P init(x).P read(x).P close(x).P

(resource access) newR xF in P
(resource creation) 0
(inaction)
x!v.P
(send) x?y.P
(receive) P1
P2 (concurrent
processes) P
(replication) (nx)P
(creation of a new channel)
if v then P1 else P2
(conditional)
Resource usage specification
7
Examples of Concurrent Programs

• (na,b,c)( initializer creates x, initializes
  and returns ) (a?r.newR xinit read close
  in init(x).r!x) ( initializer creates x,
  initializes and returns ) (b?r.newR yinit
  write close in init(y).r!y) ( finalizer
  closes x ) (c?x.close(x)) (nr,r) (
  main receives initialized resource,
  reads/writes and forwards to finalizer) (a!r
  r?x.read(x).c!x b!r r?y.write(y).c!y)

8
Main Idea of Analysis

• Extract resource-wise behavior and perform
  verification on the behavior
• Use type system for extracting behavior

9
Main Idea of Analysis

• Resource-wise behavior is represented by CCS
  process

(na,b,c) (a?r.newR xinit read close in
init(x).r!x) (b?r.newR yinit write close
in init(y).r!y) (c?x.close(x)) (nr,r)
(a!r r?x.read(x).c!x b!r r?y.write(y).c!y)
xI.r!.xR.xC
yI.r!.yW.yC
Behavior relevant to resource x
Behavior relevant to resource y
10
Main Idea of Analysis

• Resource-wise behavior is represented by CCS
  process

(na,b,c) (a?r.newR xinit read close in
init(x).r!x) (b?r.newR yinit write close
in init(y).r!y) (c?x.close(x)) (nr,r)
(a!r r?x.read(x).c!x b!r r?y.write(y).c!y)
xI.r!.xR.xC
yI.r!.yW.yC
Behavior relevant to resource x
Behavior relevant to resource y
11
Outline

• Verification Framework
• Type System
• Model Checking
• Extension to Deal with Partial Liveness
• Related Work
• Conclusion

12
Type System

• Extension of the behavioral type system
  IgarashiKobayashi TCS04
• Program behavior is abstractedby a full-CCS
  process

13
Syntax of Types
t bool res chan(ltytgtA)A 0
(inaction)
x!.A
(send) x?.A
(receive)
xx.A (resource
access) t.A
(internal action) v/xA
(renaming) ma.A
(recursive type)
Ax
(projection)
Ax
(ignoring)
a (A1 A2) A A1 A2 (nx)A
Type of communicated value (t) and how it is used
(A)
14
Type Judgment

• G P A (P behaves like A under G)
• G type environment that maps free variables in
  P to types
• A behavioral type that describes the behavior
  of P on free variables

15
Example of Judgment

• cchan(ltxres, rtgtxR.r!)
  c?(x,r).read(x).r!() c?where t
  chan(ltgt0)

16
Typing Rule for Resource Creation
Possible access sequences on resource x in A

• trace(x,A) approximates program behavior that is
  relevant to resource x

17
Typing Rule for Output
How the receiver of the message uses v
How the sender behaves after the communication
18
Typing Rule for Input
A1 simulates A2y
19
Example of Well-Typed Program

• (na,b,c) (a?r.newR xinit read close in
  init(x).r!x) (b?r.newR yinit write close
  in init(y).r!y) (c?x.close(x)) (nr,r)
  (a!r r?x.read(x).c!x b!r r?y.write(y).c!y)

c has type chan(ltxresgtxC)
20
Example of Well-Typed Program

• (na,b,c) (a?r.newR xinit read close in
  init(x).r!x) (b?r.newR yinit write close
  in init(y).r!y) (c?x.close(x)) (nr,r)
  (a!r r?x.read(x).c!x b!r r?y.write(y).c!y)

r has type chan(ltxresgtxR.xC)
c has type chan(ltxresgtxC)
21
Example of Well-Typed Program

• (na,b,c) (a?r.newR xinit read close in
  init(x).r!x) (b?r.newR yinit write close
  in init(y).r!y) (c?x.close(x)) (nr,r)
  (a!r r?x.read(x).c!x b!r r?y.write(y).c!y)

r has type chan(ltxresgtxR.xC)
This part has type xI.r!.xR.xCand trace(x,
xI.r!.xR.xC) Í I RC
22
Soundness of Type System

• If P is well-typed, P does not perform invalid
  accesses

23
Overview of Verification
Process of p-calculus
(na,b,c) (a?r.newR xinit read close in
init(x).r!x)
Type inference
CCS process asresource-wise behavior
xI.r!.xR.c!.xC
yI.r!.yW.c!.yC
Model checking
Result
Safe and partially live!
24
Type Inference Algorithm

• Given a process, returns a constraint set
  a1 A1, , trace(x1, A1) Í F1,
• By reducing the constraint, a set of trace
  inclusion constraints trace(x1, A1) Í
  F1,, trace(xn, An) Í Fnis obtained
• Typability of P is equivalent to validity of
  constraints

25
Overview of Verification
Process of p-calculus
(na,b,c) (a?r.newR init read close,x in
init(x).r!x)
Type inference
CCS process asresource-wise behavior
xI.r!.xR.c!.xC
yI.r!.yW.c!.yC
Model checking
Result
Safe and partially live!
26
Checking Constraints

• Reduce trace(x, A) Í F into inclusion problem
  between a petri-net language and a regular
  language
• Approximate A with a petri-net
• Push n (hiding) to toplevel
• Construct a petri-net that simulate A and F
  simultaneously
• Check whether illegal states are reachable

27
Outline

• Verification Framework
• Type System
• Model Checking
• Extension to Deal with Partial Liveness
• Related Work
• Conclusion

28
Partial Liveness

• All the required accesses are performed unless
  program diverges
• Process should close opened files

29
Extended Syntax

• Liveness requires deadlock-freedom

P x!tv.P
(send) x?ty.P

(receive) t (annotations on
deadlock-freedom) c
(succeed)
? (may not
succeed)

• Annotations are automatically generated by a
  separate deadlock-freedom analysis

30
Example of Annotated Program

• (na,b,c)( initializer creates x, initializes
  and returns ) (a?cr.newR xinit read close
  in init(x).r!cx) ( initializer creates x,
  initializes and returns ) (b?cr.newR yinit
  write close in init(y).r!cy) ( finalizer
  closes x ) (c?cx.close(x)) (nr,r) (
  receives initialized resource, reads/writes
  and forwards to close ) (a!cr
  r?cx.read(x).c!cx b!cr
  r?cy.write(y).c!cy)

31
Example of Annotated Program

• (na,b,c)(nd)( initializer creates x,
  initializes and returns ) (a?cr.newR xinit
  read close in init(x).r!cx) ( initializer
  creates x, initializes and returns )
  (b?cr.newR yinit write close in
  init(y).r!cy) ( finalizer closes x )
  (c?cx.d??().close(x)) (nr,r) ( receives
  initialized resource, reads/writes and
  forwards to close ) (a!cr
  r?cx.read(x).c!cx b!cr
  r?cy.write(y).c!cy)

32
Extended Types
A x!t.A
(send) x?t.A
(receive)
tt.A (internal
action)
33
Extended Rules
34
Example

• (na,b,c)(a?cr.newR xinit read close in
  init(x).r!cx) (b?cr.newR yinit write close
  in init(y).r!cy) (c?cx.close(x)) (nr,r)
  (a!cr r?cx.read(x).c!cx b!cr
  r?cy.write(y).c!cy)

trace(x, xI.r!c.xR.xC)
Í I RC
trace(yI.r!c.yW.yC) Í I
WC
35
Example

• (na,b,c)(nd)(a?cr.newR xinit read close in
  init(x).r!cx) (b?cr.newR yinit write close
  in init(y).r!cy) (c?cx.d??().close(x))
  (nr,r) (a!cr r?cx.read(x).c!cx
  b!cr r?cy.write(y).c!cy)

trace(y, yI.r!c.yW.d??,yC)
? I WC
trace(x, xI.r!c.xR.d??,xC)
? I RC
36
Implementation

• Prototype verifier is implemented
• Performs deadlock-freedom analysis using TyPiCal
  Kobayashi ActaInformatica2005
• Available at http//www.yl.is.s.u-tokyo.ac.
  jp /kohei/usage-pi/

37
Outline

• Verification Framework
• Type System
• Model Checking
• Extension to Deal with Partial Liveness
• Related Work
• Conclusion

38
Related Work

• Resource usage analysis for concurrent programs
  NguyenRathke
• Does not deal with partial liveness and dynamic
  resource creation
• Resource usage analysis for sequential programs
  IgarashiKobayashi TOPLAS05 etc.
• does not deal with concurrency

39
Related Work

• Model Checking SLAM, MWB, MMC
• Naïve application leads to state explosion
• Processes with infinite states cannot be dealt
  with
• Processes can have infinite states because of
  dynamic creation of channels and resources
• We can deal with infinite state processes if the
  resource-wise behavior can be described by a
  petri-net

40
Related Work

• Behavioral type system
• Also uses CCS-like processes as types
• IgarashiKobayashi TCS04
• Designed for checking communication behavior of
  processes
• Does not use full CCS (v/xA and (nx)A are
  omitted)
• Hiding is necessary for precise analysis
• ChakiRajamaniRehof POPL02
• Does not use full CCS (v/xA is omitted)
• Needs type annotation by programmers

41
Conclusion

• Proposed a method of resource usage analysis for
  concurrent programs
• Can deal with dynamic creation of channels and
  resources
• Can deal with both safety and partial liveness

42
Future Direction

• Evaluation of our method
• Scalability
• Effectiveness in practical examples
• Extension of the language and types
• E.g., choice
• Reusing techniques of other verification method
• Counter-example based refinement
• Abstraction of communicated values

43
Fin

• http//www.yl.is.s.u-tokyo.ac.jp/kohei/usage-pi/

44
External Resources and Safety

• External resources should be accessed in a
  certain manner
• File open (read write) close
• Violating those protocols can cause harmful result

45
Resource Usage Analysis

• Statically checking whether a program correctly
  accesses resources
• Extensively studied for sequential programs
• Type-based analysis IgarashiKobayashi et al.
  02 etc.
• Model checking Ball et al. 02 etc.
• Only a few studies for concurrent programs
• Programs with dynamic creation of resources and
  channels are not studied

46
Our Aim

• Resource usage analysis for concurrent programs
• Checked properties
• Safety
• Program does not perform illegal accesses
• Partial liveness
• All the required accesses are performed whena
  program terminates

47
Overview of Verification
Process of p-calculus
Type system that abstract process behavior with
CCS process
Type inference phase
Check whether extracted model respects resource
usage protocol
Extracted model of programs
Model checking phase
Result
48
Outline

• Target Language
• Verification of Safety
• Type System and Inference
• Model Checking Phase
• Extension to Deal with Partial Liveness
• Demo
• Related Work
• Conclusion

49
Syntax
P acc(x, x).P (access x to
resource x) newR F, x in P
(resource creation) 0
(inaction)
x!v.P
(send) x?y.P
(receive) P1 P2
(concurrent
processes) P
(replication) (nx)P
(creation of a new channel)
if v then P1 else P2
(conditional)
50
Example of Process

• newR prefix(init read close), x in (ny)(nz)
  acc(x, init).(y!() y!()) y?(). acc(x,
  read). z!() y?(). acc(x, read). z!()
  z?(). z?(). acc(x, close)

51
Outline

• Target Language
• Verification of Safety
• Type System and Inference
• Model Checking Phase
• Extension to Deal with Partial Liveness
• Demo
• Related Work
• Conclusion

52
Overview of Verification
Process of pi-calculus
Type inference phase
Extracted model of programs
Model checking phase
Result
53
Type System

• Behavioral type system Igarashi et al. 02
  extended with resource access information
• Program behavior is abstracted by a CCS process

54
Type Judgment

• G P A (P behaves like A under G)
• A behavioral type that describes the behavior of
  P
• P is safe if well-typed

55
Example of Judgment

• xchan(ltytgty!) x?y.y!true
  x?.((y!)y)where t chan(ltzboolgt0)

Type of channel which passes value that is used
once for sending
Replace y in y! with t action
56
Syntax of behavioral types
t bool res chan(ltytgtA)A 0
(inaction) x!.A (send) x?.A
(receive) xx.A t.A
v/xA ma.A Ax
Ax a (A1 A2) A A1 A2
(nx)A
57
Typing rules
Possible access sequences on resource x in A
58
Example of Trace Condition

• f newR prefix(init read close), x in
  (ny)(nz) acc(x, init).(y!() y!()) y?().
  acc(x, read). z!() y?(). acc(x, read). z!()
  z?(). z?(). acc(x, close) ( (ny)(nz)
  xinit.(y! y!) y?.xread.z!
  y?.xread.z! z?.z?.xclose
  )x

Trace of this type is included inprefix(init
read close)
59
Type Inference Algorithm

• PT(P) G, A, C
• A the behavioral type of P
• C a set of constraint
• By reducing C, a set of inclusion constraints
  trace(A1,x1) Í F1,, trace(An,xn) Í Fnis
  obtained
• P is safe if these constraints are reducible

60
Overview of Verification
Process of pi-calculus
Type inference phase
Extracted model of programs
Model checking phase
Result
61
Model Checking Phase

• Checked property trace(xinit.(y! y!)
  y?.xread.z! y?.xread.z! z?.z?.xclose)
  
  Í prefix(init read close)

62
Model Checking Phase

• Checked propertytrace(xinit.(y! y!)
  y?.xread.z! y?.xread.z! z?.z?.xclose)
  
  Í prefix(init read close)
• Encode behavioral type with petri-net
• subexpressions are places
• communications and resource accesses are
  transitions

63
Model Checking Phase

• Checked propertytrace(xinit.(y! y!)
  y?.xread.z! y?.xread.z! z?.z?.xclose)
  
  Í prefix(init read close)
• Compose the petri-net with finite state automaton

64
Model Checking Phase

• Checked propertytrace(xinit.(y! y!)
  y?.xread.z! y?.xread.z! z?.z?.xclose)
  
  Í prefix(init read close)
• Compose the petri-net with finite state automaton

65
Model Checking Phase

• Checked propertytrace(xinit.(y! y!)
  y?.xread.z! y?.xread.z! z?.z?.xclose)
  
  Í prefix(init read close)
• Check reachability
• A state from which one can make transition
  before composition, but cannot after is illegal

66
Outline

• Target Language
• Verification of Safety
• Type System and Inference
• Model Checking Phase
• Extension to Deal with Partial Liveness
• Demo
• Related Work
• Conclusion

67
Partial Liveness

• A property that all the required accesses are
  performed when a program terminates
• Examples
• newR I R C, x in (ny)(nz) acc(x, I).
  (y!().z!() y?().z?().acc(x, C))
• newR I R C, x in (ny)(nz) acc(x, I).
  (y!().z!() z?().y?().acc(x, C))

68
Dealing with Partial Liveness

• Add communication tag to each input/output using
  some analysis
• Tags are assigned by some deadlock-freedom
  analysis
• newR I R C, x in (ny)(nz) acc(x, I).
  (y!c().z!c() y?c().z?c().acc(x, C))
• newR I R C, x in (ny)(nz) acc(x, I).
  (y!f().z!f() z?f().y?f().acc(x, C))

69
Dealing with Partial Liveness

• Also add tags to behavioral types
• f newR I R C, x in (ny)(nz) acc(x,
  I). (y!c().z!c() y?c().z?c().acc(x, C))
  ((ny)(nz)xI. (y!c.z!c y?c.z?c.xC))x
• f newR I R C, x in (ny)(nz) acc(x,
  I). (y!c().z!c() z?c().y?c().acc(x, C))
  ((ny)(nz)xI. (y!f.z!f z?f.y?f.xC))x

70
Verification of Partial Liveness

• Type inference algorithm generates constraints
  trusting tags on processes
• trace(xI. (y!c.z!c y?c.z?c.xC)) Í I R C
• trace(xI. (y!f.z!f z?f.y?f.xC)) Í I R C

71
Verification of Partial Liveness

• Perform model checking
• If a state cannot make transition but automaton
  is not in accepting, then the process is not
  partially live

trace(xI. (y!f.z!f z?f.y?f.xC))
Í I R C
72
Verification of Partial Liveness

• Perform model checking
• If a state cannot make transition but automaton
  is not in accepting, then the process is not
  partially live

trace(xI. (y!f.z!f z?f.y?f.xC))
Í I R C
73
Demo

• http//www.yl.is.s.u-tokyo.ac.jp/kohei/usage-pi/

74
Outline

• Target Language
• Verification of Safety
• Type System and Inference
• Model Checking Phase
• Extension to Deal with Partial Liveness
• Demo
• Related Work
• Conclusion

75
Related Work

• Resource Usage Analysis Ball et al. 04
  IgarashiKobayashi et al. 05 Nguyen et al.
  etc.
• Only a few deal with concurrency
• Partial liveness is not dealt with
• Dynamic resource creation is not managed

76
Related Work

• Model Checking Ball et al. 02 Dam 96 Victor
  et al. 94 Yang et al. 03
• Naïve application leads to state explosion
• Processes can have infinite states with dynamic
  creation of channels and resources
• Infinite state can be finitely described with
  our behavioral type

77
Related Work

• Behavioral type system Igarashi et al. 04
  Chaki et al. 02
• Designed for checking communication behavior of
  processes

78
Conclusion

• Proposed a method of resource usage analysis for
  concurrent programs
• Need no type and usage annotation
• Can deal with dynamic creation of channels and
  resources
• We can deal with both of safety and partial
  liveness

79
Future Direction

• Evaluation of our method
• Scalability
• Effectiveness in practical examples

80
Fin

• http//www.yl.is.s.u-tokyo.ac.jp/kohei/usage-pi/

81
Typing rules
G 0 0
82
Typing rules
83
Typing rules
84
Typing rules
85
Typing rules
86
Examples of Processes

• (nc)(ns)(c?(r).newR I RC,x in
  acc(x,I).r!(x)) (s?(n,x,r). if n0 then r!()
  else acc(x,R).s(n-1,x,r)) (nr)(c!(r)
  r?(y).(nc)(s!(5,y,c) c?().acc(y,C)))

initializer
main
reader
c
s
s
initializer
main
reader
c



c
s
initializer
main
reader



87
Checking Satisfiability of Constraints

• To check trace(x, xI.(ma.(c! xR.a)
  c?.xC)) Í I RC
• Encode xI.(ma.(c! xR.a) c?.xC) with petri-net
• Compose the petri-net with the automaton for I
  R C
• And check whether illegal states are reachable

88
Example

• (nc)(ns)(c?(r).newR I RC,x in
  acc(x,I).r!(x)) (s?(n,x,r). if n0 then r!()
  else acc(x,R).s(n-1,x,r)) (nr)(c!(r)
  r?(y).(nc)(s!(5,y,c) c?().acc(y,C)))

This process is partially live if this
communication succeeds
89
Checking Satisfiability of Constraints

• trace(x, xI.(ma.(c!c xR.a) c?c.xC)) Í I RC
• Constraints are checked using model checking

90
Examples of Concurrent Programs

• newR xinit read close in (ny)(nz)
  init(x).(y!() y!()) ( initializes x,
  signals y ) ( receive signal from y, reads x,
  signals z ) y?(). read(x). z!() y?().
  read(x). z!() ( receives two signals from
  z, closes x )
• z?(). z?(). close(x)

91
Example of Judgment

• xchan(ltytgty!) x?y.y!true x?.0where t
  chan(ltzboolgt0)

Type of channel which passes a value that is used
once for sending
92
Demo

• http//www.yl.is.s.u-tokyo.ac.jp/kohei/usage-pi/

93
Checking Satisfiability of Constraints

• Checked by reducing to language containment
  problem
• trace(x, xI.r!c.xR.xC) Í I RC
• communications annotated by c succeed
• trace(x, xI.r!c.xR.d??.xC) Í I RC
• d?? may not succeed (thus, xC may not be
  performed)