Presentation is loading. Please wait.

Presentation is loading. Please wait.

Fractional Permissions without the Fractions Alex Summers ETH Zurich Joint work with: Stefan Heule, Rustan Leino, Peter Müller ETH Zurich MSR Redmond ETH.

Published by Modified over 9 years ago

Similar presentations

Presentation on theme: "Fractional Permissions without the Fractions Alex Summers ETH Zurich Joint work with: Stefan Heule, Rustan Leino, Peter Müller ETH Zurich MSR Redmond ETH."— Presentation transcript:

1 Fractional Permissions without the Fractions Alex Summers ETH Zurich Joint work with: Stefan Heule, Rustan Leino, Peter Müller ETH Zurich MSR Redmond ETH Zurich

2 Overview Verification of (race-free) concurrent programs, using (something like) fractional permissions Background Problem: picking rational values Abstract read permissions Handling calls, fork/join, monitors Permission expressions Conclusions

3 Fractional Permissions (Boyland) Provide a way of describing disciplined (race- free) use of shared memory locations. Many readers ✓ One writer ✓ Not both. Heap locations are managed using permissions ▫passed between threads, but never duplicated Permission amounts are rationals p from [0,1] ▫p=0 (no permission) ▫0<p<1 (read permission) ▫p=1 (read/write permission) Permissions can be split and recombined

4 Implicit Dynamic Frames (Smans) Uses permissions as assertions to control which threads can read/write to heap locations Permissions can be fractional Extend first-order logic assertions to additionally include “accessibility predicates”: acc(x.f, p) ; we have permission p to location x.f For example, acc(x.f,1) && x.f == 4 && acc(x.g,1) Permissions treated multiplicatively; i.e., ▫acc(x.f,p) && acc(x.f,p) ≡ acc(x.f,2p) Related to Sep. Logic * [Parkinson/Summers’11]

5 Chalice (Leino & Müller) Verification tool for concurrent programs ▫race-freedom, deadlock-freedom, functional specs Specification logic : Implicit Dynamic Frames Supports weak fractional permissions ▫acc(e.f, n%) – integer percentages (0<n ≤ 100) Also counting permissions (not discussed here) Verification conditions are generated in terms of ▫Heap variable – tracks information about heap ▫Mask variable – tracks permissions currently held Modular verification – per method declaration.

6 Inhale and Exhale “inhale P” and “exhale P” are used in Chalice to encode transfers between threads/calls “inhale P” means: ▫assume heap properties in p ▫gain permissions in p ▫havoc newly-readable locations “exhale P” means: ▫assert heap properties in p ▫check and give up permissions void m() requires p ensures q { // inhale P... // exhale P call m() // inhale Q... // exhale Q }

7 Inhale and Exhale “inhale P” and “exhale P” are used in Chalice to encode transfers between threads/calls “inhale P” means: ▫assume heap properties in p ▫gain permissions in p ▫havoc newly-readable locations “exhale P” means: ▫assert heap properties in p ▫check and give up permissions void m() requires p ensures q { // inhale P... // exhale P call m() // inhale Q... // exhale Q }

8 Inhale and Exhale “inhale P” and “exhale P” are used in Chalice to encode transfers between threads/calls “inhale P” means: ▫assume heap properties in p ▫gain permissions in p ▫havoc newly-readable locations “exhale P” means: ▫assert heap properties in p ▫check and give up permissions void m() requires p ensures q { // inhale P... // exhale P call m() // inhale Q... // exhale Q }

9 Inhale and Exhale “inhale P” and “exhale P” are used in Chalice to encode transfers between threads/calls “inhale P” means: ▫assume heap properties in p ▫gain permissions in p ▫havoc newly-readable locations “exhale P” means: ▫assert heap properties in p ▫check and give up permissions void m() requires p ensures q { // inhale P... // exhale P call m() // inhale Q... // exhale Q }

10 Inhale and Exhale “inhale P” and “exhale P” are used in Chalice to encode transfers between threads/calls “inhale P” means: ▫assume heap properties in p ▫gain permissions in p ▫havoc newly-readable locations “exhale P” means: ▫assert heap properties in p ▫check and give up permissions void m() requires p ensures q { // inhale P... // exhale P call m() // inhale Q... // exhale Q }

11 Inhale and Exhale “inhale P” and “exhale P” are used in Chalice to encode transfers between threads/calls “inhale P” means: ▫assume heap properties in p ▫gain permissions in p ▫havoc newly-readable locations “exhale P” means: ▫assert heap properties in p ▫check and give up permissions void m() requires p ensures q { // inhale P... // exhale P call m() // inhale Q... // exhale Q }

12 Inhale and Exhale “inhale P” and “exhale P” are used in Chalice to encode transfers between threads/calls “inhale P” means: ▫assume heap properties in p ▫gain permissions in p ▫havoc newly-readable locations “exhale P” means: ▫assert heap properties in p ▫check and give up permissions void m() requires p ensures q { // inhale P... // exhale P call m() // inhale Q... // exhale Q }

13 Problem / Aims We always need to specify fractional (read) permissions using precise (rational) values. ▫Manual book-keeping is tedious ▫Creates ‘noise’ in specifications, and limits re-use ▫User only cares about read or write permissions Aim: abstract over concrete permission amounts ▫User doesn’t choose amounts for read permissions Want decent performance from theorem provers Also, unbounded splitting of permissions...

14 Permission splitting class Node { Node l,r; Outcome work(Data d) requires «permission to d.f»; ensures «permission to d.f»; { if (l != null) fork outL := l.work(d); if (r != null) fork outR := r.work(d); Outcome out := /* work on this node, using d.f */ if (l != null) out.combine(join outL); if (r != null) out.combine(join outR); return out; } How much permission?

15 Idea: abstract read permissions Introduce new read permissions: acc(e.f, rd) ▫Represents an (a priori unknown), positive fractional permission ▫Positive amount: allows reading of location e.f Fractions are never expressed precisely ▫We generate (satisfiable) constraints on them ▫Specifications written using just:  read permissions: acc(e.f, rd) or simply rd(e.f)  write permissions: acc(e.f, 100%) or simply acc(e.f) ▫Different read permissions can refer to different amounts. But, sometimes we want them to match..

16 Matching rd permissions For example, method calls often take some permission and then return it to the caller: Rule: for a given method call, every rd permission in a method specification is interpreted by the same permission amount method m(c: Cell) requires rd(c.val); ensures rd(c.val); { /* do something fun... */ } method main(c: Cell) requires acc(c.val); { c.value := 0; call m(c); c.value := 1; }

17 A recursive method... method m(c: Cell) requires rd(c.val); ensures rd(c.val); { // do stuff call m(c); // do stuff } Declare fraction f m ; used to interpret rd in current method specification: 0 < f m ≤ 1 Exhale precondition for recursive call Declare 0 < f call ≤ 1 ( rd amounts in recursive call) Check that we have some permission amount assert Mask[c.val] > 0 Constrain f call to be smaller than permission we have assume f call < Mask[c.val] Give away this amount: Mask[c.val] -= f call Inhale postcondition: Mask[c.val] += f call Inhale precondition Mask[c.val] += f m Exhale postcondition Check available permission assert Mask[c.val] >= f m Remove permission from mask Mask[c.val] -= f m

18 Losing permission What if we don’t intend to return same amount? Introduce rd* method m(c: Cell) requires rd(c.val); ensures rd(c.val); { fork tk := m(c); } method m(c: Cell) requires rd(c.val); ensures rd*(c.val); { fork tk := m(c); } exhale post-condition: Check available permission assert Mask[c.val] >= f m ✘ exhale post-condition: Check some available permission assert Mask[c.val] > 0 ✓ Unknown amount returned to caller represents a different (positive) fraction – with no other information

19 Monitors Locks are associated with monitor invariants ▫inhale monitor invariant on acquire of lock ▫exhale monitor invariant on release of lock How should read permission in monitor invariants be interpreted? Recall: for methods, we “choose” a value that is convenient at each call site. Can we do the same when we transfer read permission into a monitor?

20 Monitors Analogous idea: fix fraction at release /*... */ release lock; /*... */ acquire lock; /*... */ Thread 1 class Lock { var x: int; invariant rd(x); }

21 Monitors Analogous idea: fix fraction at release Fraction needs to be fixed at object creation ▫Not possible at share for similar reasons /*... */ release lock; /*... */ acquire lock; /*... */ Thread 1 acquire lock; /*... */ release lock; Thread 2 class Lock { var x: int; invariant rd(x); }

22 Monitors method main(lock: Lock) requires rd(x); { release lock; } class Lock { var x: int; invariant rd(x); }

23 Monitors Solution 1: Use rd*(x) in monitor No guarantee that permission we get back is the same, when we re-acquire monitor method main(lock: Lock) requires rd(x); { release lock; acquire lock; } Only need to check that we have some permission. class Lock { var x: int; invariant rd*(x); }

24 Example Revisited class Node { Node l,r; Outcome work(Data d) requires «permission to d.f»; ensures «permission to d.f»; { if (l != null) fork outL := l.work(d); if (r != null) fork outR := r.work(d); Outcome out := /* work on this node, using d.f */ if (l != null) out.combine(join outL); if (r != null) out.combine(join outR); return out; }

25 Example Revisited rd permissions sufficient to specify the example class Node { Node l,r; Outcome work(Data d) requires rd(d.f); ensures rd(d.f); { if (l != null) fork outL := l.work(d); if (r != null) fork outR := r.work(d); Outcome out := /* work on this node, using d.f */ if (l != null) out.combine(join outL); if (r != null) out.combine(join outR); return out; } Some amount(s) given away, but not all Same amount(s) are retrieved

26 class Management { Data d; // shared data... void manage(Workers w) { //... make up some work out1 := call w.ask(task1, d); out2 := call w.ask(task2, d); //... drink coffee join out1; join out2; d.f := // modify data } class Workers { Outcome do(Task t, Data d, Plan p) {... } token ask(Task t, Data d) { fork out := call do(t,d,plan); return out; } } How do we know we get back all the permissions we gave away? Intuitively, ask returns the permission it was passed minus the permission held by the forked thread do requires rd access to the shared data ask requires rd access to the shared data, and gives some of this permission to the newly-forked thread

27 Permission expressions We need a way to express (unknown) amounts of read permission held by a forked thread We also need to be able to express the difference between two permission amounts We generalise our permissions: acc(e.f, P) ▫ where P is a permission expression:  100% or rd (as before)  rd(tk) where tk is a token for a forked thread  rd(m) where m is a monitor  P 1 + P 2 or P 1 - P 2 Easy to encode, and is much more expressive...

28 class Management { Data d; // shared data... void manage(Workers w) { //... make up some work out1 := call w.ask(task1, d); out2 := call w.ask(task2, d); //... drink coffee join out1; join out2; d.f := // modify data } class Workers { Outcome do(Task t, Data d, Plan p) {... } token ask(Task t, Data d) { fork out := call do(t,d,plan); return out; } requires acc(d.f, rd) ensures acc(d.f, rd – rd(result)) requires acc(d.f, rd) ensures acc(d.f, rd) requires acc(d.f, 100%) ensures acc(d.f, 100%)

29 class Management { Data d; // shared data... void manage(Workers w) { //... make up some work // 100% out1 := call w.ask(task1, d); out2 := call w.ask(task2, d); //... drink coffee join out1; join out2; d.f := // modify data } class Workers { Outcome do(Task t, Data d, Plan p) {... } token ask(Task t, Data d) { fork out := call do(t,d,plan); return out; } requires acc(d.f, rd) ensures acc(d.f, rd – rd(result)) requires acc(d.f, 100%) ensures acc(d.f, 100%) requires acc(d.f, rd) ensures acc(d.f, rd)

30 class Management { Data d; // shared data... void manage(Workers w) { //... make up some work // 100% out1 := call w.ask(task1, d); // 100% - rd(out1) out2 := call w.ask(task2, d); //... drink coffee join out1; join out2; d.f := // modify data } class Workers { Outcome do(Task t, Data d, Plan p) {... } token ask(Task t, Data d) { fork out := call do(t,d,plan); return out; } requires acc(d.f, rd) ensures acc(d.f, rd – rd(result)) requires acc(d.f, 100%) ensures acc(d.f, 100%) requires acc(d.f, rd) ensures acc(d.f, rd)

31 class Management { Data d; // shared data... void manage(Workers w) { //... make up some work // 100% out1 := call w.ask(task1, d); // 100% - rd(out1) out2 := call w.ask(task2, d); // 100% - rd(out1) – rd(out2) //... drink coffee join out1; join out2; d.f := // modify data } class Workers { Outcome do(Task t, Data d, Plan p) {... } token ask(Task t, Data d) { fork out := call do(t,d,plan); return out; } requires acc(d.f, rd) ensures acc(d.f, rd – rd(result)) requires acc(d.f, 100%) ensures acc(d.f, 100%) requires acc(d.f, rd) ensures acc(d.f, rd)

32 class Management { Data d; // shared data... void manage(Workers w) { //... make up some work // 100% out1 := call w.ask(task1, d); // 100% - rd(out1) out2 := call w.ask(task2, d); // 100% - rd(out1) – rd(out2) //... drink coffee join out1; join out2; // 100% d.f := // modify data } class Workers { Outcome do(Task t, Data d, Plan p) {... } token ask(Task t, Data d) { fork out := call do(t,d,plan); return out; } requires acc(d.f, rd) ensures acc(d.f, rd – rd(result)) requires acc(d.f, 100%) ensures acc(d.f, 100%) requires acc(d.f, rd) ensures acc(d.f, rd)

33 class Management { Data d; // shared data... void manage(Workers w) { //... make up some work // 100% out1 := call w.ask(task1, d); // 100% - rd(out1) out2 := call w.ask(task2, d); // 100% - rd(out1) – rd(out2) //... drink coffee join out1; join out2; // 100% d.f := // modify data // ✓ can write } class Workers { Outcome do(Task t, Data d, Plan p) {... } token ask(Task t, Data d) { fork out := call do(t,d,plan); return out; } requires acc(d.f, rd) ensures acc(d.f, rd – rd(result)) requires acc(d.f, 100%) ensures acc(d.f, 100%) requires acc(d.f, rd) ensures acc(d.f, rd)

34 Monitors Recall the awkward situation with monitors: method main(Lock: lock) requires rd(x); { release lock; acquire lock; } class Lock { int x; invariant rd(x); }

35 Monitors Solution 2: Using the permission expressions Now we can express exactly the amount of permission we need to exhale to the monitor. method main(Lock lock) requires acc(x,rd(lock)); { release lock; acquire lock; } class Lock { int x; invariant rd(x); }

36 Summary and Extras Presented a specification methodology: ▫similar expressiveness to fractional permissions ▫avoids explicit “values” for read permissions ▫allows user to reason about read/write abstractly Supports full Chalice language ▫fork/join, channels, predicates, loop invariants Methodology is implemented ▫backwards-compatible with a few easy edits ▫permission encoding uses only integer-typed data ▫performance comparable with existing encoding

37 Future Work We cannot express the permission left over after we fork off an unbounded number of threads ▫mathematical sums in permission expressions ▫e.g., acc(x, 100% – Σ i rd(tk i )) ▫some careful encoding is required to perform well In some obscure cases, permission multiplication arises ▫non-linear arithmetic tends to perform badly Experiment with encoding harder fractional examples using abstract permission expressions

38 Are there any questions?

Download ppt "Fractional Permissions without the Fractions Alex Summers ETH Zurich Joint work with: Stefan Heule, Rustan Leino, Peter Müller ETH Zurich MSR Redmond ETH."

Similar presentations

1 Lecture 5 Towards a Verifying Compiler: Multithreading Wolfram Schulte Microsoft Research Formal Methods 2006 Race Conditions, Locks, Deadlocks, Invariants,

1 Lecture 5 Towards a Verifying Compiler: Multithreading Wolfram Schulte Microsoft Research Formal Methods 2006 Race Conditions, Locks, Deadlocks, Invariants,
Joint work with Mike Barnett, Robert DeLine, Manuel Fahndrich, and Wolfram Schulte Verifying invariants in object-oriented programs K. Rustan M. Leino.

Joint work with Mike Barnett, Robert DeLine, Manuel Fahndrich, and Wolfram Schulte Verifying invariants in object-oriented programs K. Rustan M. Leino.
Writing specifications for object-oriented programs K. Rustan M. Leino Microsoft Research, Redmond, WA, USA 21 Jan 2005 Invited talk, AIOOL 2005 Paris,

Writing specifications for object-oriented programs K. Rustan M. Leino Microsoft Research, Redmond, WA, USA 21 Jan 2005 Invited talk, AIOOL 2005 Paris,
Technologies for finding errors in object-oriented software K. Rustan M. Leino Microsoft Research, Redmond, WA Lecture 3 Summer school on Formal Models.

Technologies for finding errors in object-oriented software K. Rustan M. Leino Microsoft Research, Redmond, WA Lecture 3 Summer school on Formal Models.
Technologies for finding errors in object-oriented software K. Rustan M. Leino Microsoft Research, Redmond, WA Lecture 1 Summer school on Formal Models.

Technologies for finding errors in object-oriented software K. Rustan M. Leino Microsoft Research, Redmond, WA Lecture 1 Summer school on Formal Models.
Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?

Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
Lecture 4 Towards a Verifying Compiler: Data Abstraction Wolfram Schulte Microsoft Research Formal Methods 2006 Purity, Model fields, Inconsistency _____________.

Lecture 4 Towards a Verifying Compiler: Data Abstraction Wolfram Schulte Microsoft Research Formal Methods 2006 Purity, Model fields, Inconsistency _____________.
Challenges in increasing tool support for programming K. Rustan M. Leino Microsoft Research, Redmond, WA, USA 23 Sep 2004 ICTAC Guiyang, Guizhou, PRC joint.

Challenges in increasing tool support for programming K. Rustan M. Leino Microsoft Research, Redmond, WA, USA 23 Sep 2004 ICTAC Guiyang, Guizhou, PRC joint.
Substitution & Evaluation Order cos 441 David Walker.

Substitution & Evaluation Order cos 441 David Walker.
Synthesis, Analysis, and Verification Lecture 04c Lectures: Viktor Kuncak VC Generation for Programs with Data Structures “Beyond Integers”

Synthesis, Analysis, and Verification Lecture 04c Lectures: Viktor Kuncak VC Generation for Programs with Data Structures “Beyond Integers”
Abstraction and Modular Reasoning for the Verification of Software Corina Pasareanu NASA Ames Research Center.

Abstraction and Modular Reasoning for the Verification of Software Corina Pasareanu NASA Ames Research Center.
Constraint Semantics for Abstract Read Permissions 28 th July 2014, FTfJP, Uppsala John Tang Boyland (UW-Milwaukee/ETH Zurich) Peter Müller, Malte Schwerhoff,

Constraint Semantics for Abstract Read Permissions 28 th July 2014, FTfJP, Uppsala John Tang Boyland (UW-Milwaukee/ETH Zurich) Peter Müller, Malte Schwerhoff,
Automated Verification with HIP and SLEEK Asankhaya Sharma.

Automated Verification with HIP and SLEEK Asankhaya Sharma.
Automated Software Verification with a Permission-Based Logic 20 th June 2014, Zürich Malte Schwerhoff, ETH Zürich.

Automated Software Verification with a Permission-Based Logic 20 th June 2014, Zürich Malte Schwerhoff, ETH Zürich.
Goldilocks: Efficiently Computing the Happens-Before Relation Using Locksets Tayfun Elmas 1, Shaz Qadeer 2, Serdar Tasiran 1 1 Koç University, İstanbul,

Goldilocks: Efficiently Computing the Happens-Before Relation Using Locksets Tayfun Elmas 1, Shaz Qadeer 2, Serdar Tasiran 1 1 Koç University, İstanbul,
Verification of Multithreaded Object- Oriented Programs with Invariants Bart Jacobs, K. Rustan M. Leino, Wolfram Schulte.

Verification of Multithreaded Object- Oriented Programs with Invariants Bart Jacobs, K. Rustan M. Leino, Wolfram Schulte.
A simple sequential reasoning approach for sound modular verification of mainstream multithreaded programs Wolfram Schulte & Bart Jacobs Microsoft Research.

A simple sequential reasoning approach for sound modular verification of mainstream multithreaded programs Wolfram Schulte & Bart Jacobs Microsoft Research.
K. Rustan M. Leino Research in Software Engineering (RiSE) Microsoft Research, Redmond, WA, USA 3 December 2008 U. Lugano Lugano, Switzerland.

K. Rustan M. Leino Research in Software Engineering (RiSE) Microsoft Research, Redmond, WA, USA 3 December 2008 U. Lugano Lugano, Switzerland.
ISBN 0-321-33025-0 Chapter 3 Describing Syntax and Semantics.

ISBN Chapter 3 Describing Syntax and Semantics.
Changing perspective can be useful Relating alternative logics for automatic software verification Alex Summers (ETH Zurich) partly based on joint work.

Changing perspective can be useful Relating alternative logics for automatic software verification Alex Summers (ETH Zurich) partly based on joint work.

Similar presentations

Ads by Google