14.3 The fancy update modality and weakest precondition
Finally, we have rules connecting the new update modality to the weakest precondition asser-tion, and thus to Hoare triples and program specfications. These rules generalise several of the rules we have seen before. In particularHt-inv-alloc,Ht-inv-openand the previous ruleHt-csq will be derivable from the rules introduced in this section.
The rules for the relationship between the fancy update modality and weakest preconditions are listed in Figure12. The rulewp-vupstates that we can remove the update modalities around
wp-vup
Figure 12: Rules connecting fancy view shifts to the weakest precondition assertion.
and inside the weakest precondition assertion. This is important because in general we do not have|VEP `P, and so proving|VEP is weaker than provingP. The rulewp-vupstates that this is not the case for the weakest precondition assertion. We can use this rule to, for example, do frame preserving updates inside the weakest precondition assertion.
Exercise 14.7. Derive the following rule.
a b
wpEe{v.Φ(v)∗aγ} `wpe{v.Φ(v)∗bγ}
♦
Next is the rulewp-atomic, which is similar to the ruleHt-inv-open. It is crucial here thateis an atomic expression. If it was not then a similar counterexample as the one for the rule Ht-inv-open, which is explained in Example8.6, would apply, and the weakest precondition assertion would not be sound for the operational semantics of the language. The rule is very general, so let us see how it allows us to recover some rules for working with invariants.
Example 14.8. LetEbe a set of invariant names andι∈ Eandean atomic expression. We derive the following rule for accessing invariants using the weakest precondition assertion.
wp-inv-open The rule derived in the preceding example can be strengthened somewhat.
Exercise 14.9. Derive the following rules. These rules perhaps look rather strange, however they show that as long as we are proving a weakest precondition we can most of the time strengthen the assumptions by removing the fancy update modalities, provided the masks match. The rules are thus quite crucial in concrete proofs, and are often used implicitly. In particular when Iris is used in Coq via the interactive proof mode (see Section15) these, and related rules, are used by the tactics behind the scenes.
♦ As we mentioned above the rule wp-atomic is similar to the ruleHt-inv-open. In fact, the latter is derivable from the rule we derived in Example14.8, as we now demonstrate.
Example 14.10(Derivation ofHt-inv-openfromwp-inv-open). Letebe an atomic expression. We are to show
Ht-inv-open
S∧Iι`{. I∗P}e{v. . I∗Φ(v)}E \{ι} S∧Iι`{P}e{Φ}E
recalling that we have defined{P}e{Φ}E as(P −∗wpEe{Φ}). Let us show it. Since invariants and Hoare triples are persistent we have
S∧Iι`(S∧Iι)∧Iι
`({. I∗P}e{v. . I∗Φ(v)}E \{ι})∧Iι
`
{. I∗P}e{v. . I∗Φ(v)}E \{ι}∗Iι and thus it suffices to show
{. I∗P}e{v. . I∗Φ(v)}E \{ι}∗Iι`P −∗wpEe{Φ}. bypersistently-mono. In fact bypersistently-Eit suffices to show
. I∗P −∗wpE \{ι}e{v. . I∗Φ(v)}
∗Iι`P −∗wpEe{Φ}
which is equivalent to showing
. I∗P −∗wpE \{ι}e{v. . I∗Φ(v)}
∗Iι∗P `wpEe{Φ}
by the wand introduction rule. Now . I∗P −∗wpE \{ι}e{v. . I∗Φ(v)}
∗Iι∗P `
. I−∗wpE \{ι}e{v. . I∗Φ(v)}
∗Iι by the wand elimination rule, which in turn yields
wpEe{Φ}
bywp-inv-openderived in Example14.8.
The final rule iswp-frame-step. This is analogous to the ruleHt-frame-atomic, which allows us to remove laters from frames in the precondition, provided the term is atomic. Here, the term is not required to be atomic, but it is important that it is not a value. The fancy update modalities included in the rule are useful in certain cases, thus the rule is stated in full generality.
Exercise 14.11. Derive the following rules fromwp-frame-step. e<Val
. P ∗wpEe{Φ} `wpEe{v.P∗Φ(v)}
e<Val S`{P}e{v.Q}E S`{P∗. R}e{v.Q∗R}E
To derive the first rule, recall thatP `E|VEP for anyP and any maskE. ♦ Finally, note that there is no special rule needed for allocating invariants in connection with weakest preconditions. This is in contrast to Hoare triples, where allocating an invariant means transferring resources from thepreconditionto the invariant. With weakest preconditions allo-cation of invariants is handled separately, and interaction of invariants and weakest precondi-tions is governed by the fancy update modality.
Fancy view shifts Finally, we define the fancy view shiftP E1VE2 Qfrom the fancy update modality as
P E1VE2Q, (P −∗E1|VE2Q).
IfE1=E2we writeP VE1 QforP E1VE1 Q. This concept is analogous to how view shifts are defined from the update modality in Section8. The concept makes it easier to state some of the (derived) rules involving Hoare triples.
Exercise 14.12. Derive the following rules for the fancy view shift.
•
Fvs-refl
· `P VE1P
Fvs-trans
S`P E1VE2Q S`Q E2VE3R S`P E1VE3R
•
Fvs-imp S`(P ⇒Q)
S`P VEQ
Fvs-wand S`(P −∗Q)
S`P VEQ
•
Fvs-frame
S`P E1VE2Q S`P∗R E1VE2Q∗R
Fvs-mask-frame
S`P E1VE2Q (E1∪ E2)∩ Ef =∅ S`P∗R E1]EfVE2]Ef Q∗R
•
Fvs-timeless
`P timeless
· `. P VEP
•
Fvs-alloc-I Einfinite
· `. P ∅V∅∃ι∈ E. P ι
Fvs-open-I
Pι`True {ι}V∅. P
♦
Hoare triples and fancy view shifts With the new concepts we can present the final general-isation of the rules for Hoare triples. The most general rule of consequence we consider is the following
Ht-csq
S`P0 EVEP S`{P}e{v.Q}E S` ∀v. Q(v) EVEQ0(v) S`{P0}e{v.Q0}E
From now onHt-csqwill refer to this instance.
Exercise 14.13. Derive the above rule of consequence. ♦ The next rule is a generalisation ofHt-frame-atomic.
Ht-frame-step
e<Val S`{P}e{v.Q}E
2 S`R1 E1VE2. R2 S`R2 E2VE1R3 E2⊆ E1 S`{P∗R1}e{v.Q∗R3}E
1
It allows us to remove the later modality from the frame in cases where the termeis not a value.
The side-condition in the rule corresponds to the side-condition in the rulewp-frame-step. Exercise 14.14. Derive the ruleHt-frame-stepfrom the rulewp-frame-step. ♦ Example 14.15(Improved Specfication for the Spin Lock). In this example we will show how to use the fancy update modality to give a better specification of the spin lock module from Section8.6.
First, recall the specification we gave earlier for the spin lock module:
∃isLock : Val→Prop→GhostName→Prop.
∃locked :GhostName→Prop.
(∀P , v, γ.isLock(v, P , γ)⇒isLock(v, P , γ))
∧ ∀γ.locked(γ)∗locked(γ)⇒False
∧ ∀P .{P}newLock(){v.∃γ.isLock(v, P , γ)}
∧ ∀P , v, γ.{isLock(v, P , γ)}acquirev{.P∗locked(γ)}
∧ ∀P , v, γ.{isLock(v, P , γ)∗P∗locked(γ)}releasev{ .True}
Notice that the resource invariant, the predicate P, is in the precondition for the newLock method. This means that that a client of the lock module must allocate the resources, which the lock is going to protect,beforecalling the newLock method. For example, we cannot use the above specification to verify safety of the following simple client, where the intention, of course, is that the lock should protect the referencer.
C1≡letl= newLock()in letr=ref(0)inacquirel;r←!r+ 1; releasel
The problem is that when newLock is called, referenceris not in scope and thus we cannot instantiateP with our intended resource invariant∃n.r ,→nwhen attempting to verify the call to newLock. Thus with the specification given above, we are forced to rewrite the client code as follows:
C2=letr=ref(0)in letl= newLock()inacquirel;r←!r+ 1; releasel
so that the resource (here the referencer) is allocated before newLock is called. In general this is undesirable since the two programs are completely equivalent, and thus the logic should not force us to make trivial changes to the program in order to verify them.
Let us instead consider the following specification of the newLock method:
{True}newLock(){v.∃γ.∀P . P −∗ |V∅isLock(v, P , γ)} (48) This specification expresses that we can always call newLock (since the precondition isTrue) and, moreover, that when newLock returns, we get the assertion
∀P . P −∗ |V∅isLock(v, P , γ). (49)
The idea is that we can use this assertion when we know what the resource invariantP should be instantiated with. Then, when we have the resourcesP, we can use the assertion (49) to obtain|V∅isLock(v, P , γ), which is equivalent to isLock(v, P , γ) if it appears in the pre- or post-condition of a Hoare triple,i.e.,the following inference rules are valid.
{P}e{v.Q}E {|V∅P}e{v.Q}E
{P}e{v.|V∅Q}E {P}e{v.Q}E
Exercise 14.16. Derive the preceding two rules from the rule of consequence. ♦ Remark 14.17. Notice that theP −∗ |V∅isLock(v, P , γ) is almost a fancy view shift, except for the missingmodality. The specification with a fancy view shift,i.e.,
{True}newLock(){v.∃γ.∀P .(P −∗ |V∅isLock(v, P , γ))} (50) would beunsoundin the sense that isLock(v, P , γ) would not protect the resources as explained in the following exercise. It would allow us to conjure up many different independent locks protecting the same resource, meaning none of the locks would actually protect the resource.
Exercise 14.18. Letebe the following program.
letv= newLock()in let`=ref(0)in acquirev;
releasev;
acquirev;
letn= !`inreleasev;n
Assuming (50) as the specification for newLock show the following specification.
{True}e{v.v= 37}. ♦
The specifications of the acquire and release methods stay the same.
Exercise 14.19.
1. Use the new lock module specification to verify the safety of the first client program, by showing the following specification:
{True}C1{True}
2. Prove that the newLock method for the spin lock implementation in Section8.6satisfies
the specification in (48). ♦