A Survey of
Rely-Guarantee Approaches in
Compositional Verification
Murat Demirbas
OSU
Typical verification methods:
• Deduction:
– Temporal and Modal Logic, Emerson 90
– TLA, Lamport 94
– UNITY Logic, Chandy & Misra 88
• Model Checking
Typical verification methods:
• non compositional
• require a global examination of the entire system
• effective on small examples, however, fail to scale up for large-scale systems
A plea for Compositional
Verification
•
≜ any automaton with 10 states
• A ≜ parallel composition of 80 of such
’s
• A has 10 80 states
– Greater than the # of electrons in the universe
• Now, consider the Internet …
• The verification method should scale linearly rather than exponentially in the number of components
Compositional Verification
Methods:
• shift the burden of verification from the global level to the component (local) level
• so that global properties are established by composing independently verified component properties.
Compositional Verification
Methods: (cont.)
• Enables us to verify whether a program meets its spec on the basis of the specs of its components (without assuming any knowledge of the interiors of those components).
Rely-Guarantee Approach
• The best studied approach to compositional verification
• A rely-guarantee spec for M is
(R, G)
– R: the conditions that M relies on its environment to provide
– G: the conditions that M guarantees in return
Rely-Guarantee Approach (cont.)
• The intuition for using R-G specs for M
– M needs to behave correctly only when its environment does
• M ⊨ (R,G) : the environment of M violates
R before M fails to satisfy G
Composition Principle
Let M be the composition of M i
• j:: R
/\ G i
R j
• i:: M i
⊨ (R i
, G i
)
• /\
G i
G s.t. i
I. If
Then
M ⊨ (R,G)
1
M
Cyclic Dependencies c output var c initially 0; input var d; loop endloop
<c:=d>
2
M d output var d initially 0; input var c; loop
<d:=c> endloop
Safety properties in Rely
• M
1
– R
1
: always d=0
– G
1
: always c=0
• M
2
– R
2
: always c=0
– G
2
: always d=0
• M ≜ M
1
• R: true
|| M
2
• G: always c=0
d=0
Liveness properties in Rely
• M
1
– R
1
: eventually d=1
– G
1
: eventually c=1
• M
2
– R
2
: eventually c=1
– G
2
: eventually d=1
• M ≜ M
1
• R: true
|| M
2
• G: ???
Outline
1. History of compositional verification
2. Stark’s work
3. Abadi & Lamport’s work
4. Lazy composition
5. Modified Rely-Guarantee rules
6. Other work
7. Rely-Guarantee wrappers for f-t
8. Conclusion
1. History of Compositional
Verification
• Compositionality in predicate logic,
Frege
1923
• Sequential program verification
– Inductive assertion method (non compositional), Floyd 67
– axiomatic compositional proof style,
Hoare 69
History of Compositional
Verification (cont.)
• Concurrent & distributed systems
– Proof system for shared variable concurrency: interference freedom test (non compositional),
Owicky & Gries 76
– Temporal logic (non compositional), Pnueli 77
– Rely-guarantee formalism (compositional),
Misra & Chandy 81
– Rely-guarantee formalism for safety properties in shared-memory, Jones 81, 83
Misra & Chandy: Proofs of
Network of Processes
• Spec for a process M i is “ R i
| M i
| G i
”
– G i holds for empty trace
– for all traces t of M i of t, then G of t i
, if R i holds for all proper prefixes holds for all prefixes (proper & improper)
• R | M | G holds if
– R /\
G i
– i:: R i
| M i
| G i
/\
R j
– /\
G i
G
Hoare’s proof rule is an instance of composition principle
• Precondition: the rely of the program on the program state when the control reaches that point
• Postcondition: what the program guarantees in return if and when the control leaves that point
• Limited to the verification of safety properties only
M = M
1
;M
2
• If
– R
R
1
, {R
1
}M
1
{G
1
},
– G
1
R
2
, {R
2
}M
2
{G
2
}, G
2
G
• Then
{R}M{G}
– R
G
1
G
2
R
1 ,
– M
1
⊨ (R
1
, G
1
),
– G
1
G
2
G
R
G
1
G
2
R
2
M i
⊨ (R i
, G i
)
2. Stark’s Proof Technique for
Rely-Guarantee Properties
• Stark’s proof technique rules out circular dependencies in liveness conditions; one can derive global liveness properties of a system from its components’ liveness properties.
Stark’s work
• Intuition: Find a set of specs that “cuts” the dependence between a component M i and its environment. Analogy: loop invariant
• RG i,j
= what M i relies on M i guarantees to M to provide j
= what M j
{RG i,j
: i,j
I
{ext}} is a cut set:
• R /\ j
I
RG ext,j
• /\ i
I
RG i,ext
G
• ( j:: /\ i
I
{ext}
RG i,j
R j
)
• ( i:: G i
/\ j
I
{ext}
RG i,j
)
Acyclic cut sets
• If no R i holds, then no G does not hold i holds, hence G
• m:: \/ k
{0...m-1}
RG ik, ik+1
• Finding a cut set is analogous to finding a loop invariant, no algorithm exists
Rely-Guarantee Proof Rule
• M is a program, RG is an acyclic cut set for
M, R, G, and {R i
, G i
: i
I}
• If ( i: i
I : M ⊨ (R i
, G i
) )
• Then
M ⊨ (R, G)
Examples
• Verification of a mutual exclusion algorithm
(token ring ME)
• Verification of a distributed resource allocation algorithm
• The proof technique is compared against other liveness proof techniques such as
Proof Lattice Method (Lamport & Owicky), and Variant Function Method (Floyd)
3. Abadi & Lamport’s work
• Composing Specifications
, 92
• Conjoining Specifications
, 93
• Main thm: If all the “rely” specifications (R,
i:: R i
) are safety properties, then circularity in “Composition Principle” is safe (i.e., does not lead to circular reasoning).
Stuttering Equivalence
• Specifications should allow “stuttering” steps that leave the state unchanged.
• Consider F, G. A behavior of their composition is obtained by interleaving actions from the two components.
• However, this interleaved behavior does not satisfy F, since it contains steps that do not belong to actions of F, nor does it satisfy G.
Conjoining Specs
• Parallel composition is conjunction.
• Temporal Logic of Actions
• Composition thm
• Decomposition thm
(R,G) ≜ R→ + G (R secures G)
• R → + G ≜ {σ
R
G |
i: σ[i]
S(R)
σ[i+1]
S(G) }
• S(R)
:the strongest safety property containing R
(i.e., safety closure of R)
• R → + G rules out unrealizable implementations of
R
G where S(G) fails before the failure of S(R) can be detected by the component.
• R
G
R → + G for machine realizable specs.
They allow the same implementations.
Safety properties in rely specs
• R → + G ≜ (R
G)
(S(R) → + S(G))
• R → + G = S(R) → + (S(G)
(R
G))
• Thus, any rely/guarantee spec can be converted to one whose rely is a pure safety property.
Composition Thm
Let M be the composition of M i s.t. i
I. If
• j:: S( R )
/\ S(
• i:: M i
⊨ (R i
, G i
G i
)
R j
) (i.e.,
i:: R i
→ + G i
)
• R → + ( /\ G i
G)
Then
M ⊨ (R,G) (i.e., R → + G )
Decomposition Problem
• Let
M ≜ M
1
M l n
.
|| …|| M n
, M l ≜ M l
1
|| …||
• Prove that M l implements M by proving
((E, /\ i
I
M l i
)
(E, /\ i
I
M i
))
• Trivially true if
(
i: i
I : M l i
M i
)
• However, M l i
M i is not necessarily the case in top down refinements of a system.
Decomposition
• We can relax M l i
M i and still reason about one component at a time:
– ( i: i
I: E i
M l i
M i
)
• However, the composition principle requires proving (
i: i
I: ( /\ k
I
M l k
E i
)
• Instead, we can avoid reasoning about the entire low level system:
– ( i: i
I: ( /\ k
I
M k
E i
))
Decomposition Thm
If
• j:: S(E)
/\ S(M i
)
E j
• E i
→ + (M l i
Then
M i
)
E → + ( /\ i
I
M l i
/\ i
I
M i
)
Queue example
• Q1, Q2: queues of length N.
• Q of length 2N+1 can be obtained by composing Q1 and Q2.
• The example is wrong
– Q1 and Q2 refer to N
– Q1 and Q2 are not aware of each other
• Shankar 97 presents a buffer example very similar to the queue example
4. Lazy Composition, Shankar 97
• Difficult to apply R-G specs to composition
– G i should be strong enough to imply any potential constraint R j
.
– It is not easy to anticipate all the potential constraints that might be placed on M i
.
• In lazy composition G i the system M i
|| E i of M i where E i is proved of captures the expected behavior of the abstract environment for M i
.
Lazy Composition (cont.)
• G i might not hold for M i holds for M i
|| (M j
E i
).
|| M j
, however it
– Thus, the proof obligation that M j satisfies E i can be delayed till later.
• Lazy composition: cited as the main contribution of the paper
– Same delay of proof is also possible for the regular R-G specs.
Composition
• Let M e
1
= M
1
|| E
1
• Closed co-imposition
– M e
1
M e
2
≜ (M
1
E
2
) || (M
2
E
1
)
• Open co-imposition
– M e
1
M e
2
≜ M e
1
M e
2
|| (E
1
E
2
)
• Thm:
[M e
1
M e
2
]
[M e
1
]
[M e
1
M e
2
]
[M e
1
]
Elimination of E i
’s by using
Refinement Proofs
• One can show that
(M
1
E
2
) || (M
2
E
1
) || (E
1
E
2
) is refined by
M
1
|| (M
2
E
1
) || (E
1
E
2
) to eliminate E
2
• This is the main advantage of this approach
– we do not have to prove G
1
→ + R
2
– instead we can employ a refinement proof to eliminate E
2
(i.e. to satisfy R
2
)
5. Modified Rely-Guarantee rules, Manohar, Sivilotti 96
• M ⊨ (R,G) ≜ (
E:: (E||M ⊨ R)
(E||M ⊨
G))
– Thus, one has to consider all E to prove above.
• Modified Rely-Guarantee:
R and G can refer only the local variables in M.
• M ⊨ (R ⌦ G) ≜ (M ⊨ R)
(M ⊨ G) .
Modified Rely-Guarantee rules
(cont.)
• Compositionality:
– Let M ⊨ (R ⌦ G)
– Then (
N:: M||N ⊨ (R ⌦ G) )
• Handles the verification of liveness properties easily.
Composition Thm
Let M be the composition of M i
• j:: R
( /\
• i:: M i
⊨ (R i i<j
R i
⌦ G i
)
G i
)
R j
Then
M ⊨ (R ⌦ (
i:: R i
G i
) ) s.t. i
I. If
Composition Thm: (safety props)
Let M be the composition of M i
• i:: R i
,G i are safety properties s.t. i
I. If
• j:: R
/\ G
• i:: M i
⊨ (R i i
R j
⌦ G i
)
Then
M ⊨ (R ⌦ (
i:: R i
G i
) )
Examples
• K mutual exclusion in a ring (works very good)
• Synchronization with Gossip
6. Other work
• The need for compositional proof systems, deRoever 97
– Decomposition thm Dijkstra’s verify while develop approach
• Systematic composition of distributed objects:
Processes & Sessions, Chandy & Rifkin 97
– Considers Internet (anarchic system) as an application of bottom up design using composition
Other work (cont.)
• Composition: A way to make proofs harder,
Lamport 97
– Decomposition thm is popular only because it can be expressed in terms of PPL favored by
CS people
– Decomposition thm is not necessary; when a system is specified using mathematics, decomposition trivially follows from math.
Other work (cont.)
• Towards a compositional approach to the design & verification of distributed systems,
Charpentier&Chandy
– UNITY framework
– Resource allocator example
• Both top-down and bottom-up approaches used
– A component should publish its provided spec as well as different weaker specs to simplify reuse in different applications.
7. Rely-Guarantee wrappers for fault-tolerance
• Let M be the composition of M i
• Compositionality principle holds s.t. i
I.
– ( i:: M i
⊨ (R i
, G i
))
M ⊨ (R,G)
– I.e., ( i:: S i
)
S
Rely-Guarantee wrappers (cont.)
• S’ i
≜ (Fspan(R i
) , G i
)
:masking F-tolerant version of M i
= M’ i
• S’’ i
≜ (Fspan(R i
(Fspan(R i
) , S i
) , (S
S(G i i
)) unless
R i
)
S(G
:fail-safe F-tolerant version of M i
= M’’ i i
))
• S’’’ i
≜ (Fspan(R i
) , S i
(True ↦ R i
:nonmasking F-tolerant M i
= M’’’ i
))
Rely-Guarantee wrappers (cont.)
• Let w’ i get M’ i be the wrapper to be added to M i
(i.e., M’ i
≜ w’ i
|| M i
) to
• R1: Calculate R-G specs for w’ i
• S i
w’ i
= S’ i then w’ i
≜ S i
, w’’
S’ i i
, w’’’ i
• w’’ i
• w’’’ i
≜ ( S i
,
S’’ i
)
( S i
, (FSpan (R i
)
S(G i
) )
≜ ( S i
,
S’’ i
)
( S i
, (FSpan (R i
) ↦ R i
) )
Proposal:
• Problem: How to calculate FSpan(R i
)?
• Using modified R-G would help
– local reasoning while calculating FSpan(R i
)
– In general, we might not avoid global reasoning
• Use abstract faulty environment E F i
– Lazy composition for refinement proofs
• If F is a transient fault: FSpan(R i
) =True
Rely-Guarantee wrappers (cont.)
• R2: Prove that
– ( i:: S’ i
)
S’
– ( i:: S’’ i
)
S’’
– ( i:: S’’’ i
)
S’’’
• Can M be made F-tolerant by composing each M i with w i
?
R2
Need to show
– j:: R x
/\
G x i
R x j
– R x
/\
G x
G x i
To deduce (
i:: R x i
G x i
)
(R x
G x )
• Easy for closed systems (R=True);
– reuse criterion G x i
– R i
Fspan(R j
)
G j
– Interference freedom rule might be needed for nonmasking f-t
8. Conclusion
• (R,G) specs provide a natural (and also graybox ) way to specify components
• Composition (via conjunction) provides a simple but powerful model for reasoning about large-scale distributed programs
• It is a good model to study graybox dependability wrappers