Correct Concurrency with Chalice

1. Correct Concurrency with Chalice Rustan Leino RiSE, Microsoft Research, Redmond Joint work with: Peter Müller, ETH ZurichJan Smans, KU Leuven MIT 5 June 2009

2. Some textbook concepts classCell { intval; invariantval > 0; void Set( int v ) { lock( this ) { val := v; } } void Swap( Cell c ) { lock( this ) { lock( c ) { int t := val; val := c.val; c.val := t; } } } } • Atomicity • Sequential reasoning within atomic sections • Monitor invariants • Assumed when monitor is acquired • Checked when monitor is released • Locking order • Deadlock prevention • Rely-guarantee reasoning • Thread interference

3. Challenges • Client-side locking • One monitor protects lots of state • Fine-grained locking • One field protected by several monitors • Thread-local and shared objects • Transitions in both directions • Dynamic changes of locking order classNode { intval; Node next; invariant next nullval next.val; …} classList { Node head; void Reverse( ) { … } …}

4. Chalice • Experimental language with focus on: • Share-memory concurrency • Static verification • Key features • Memory access governed by a model of permissions • Sharing via locks with monitor invariants • Deadlock checking, dynamic lock re-ordering • Other features • Classes; Mutual exclusion and readers/writers locks;Fractional permissions;Two-state monitor invariants;Asynchronous method calls; Memory leak checking;Logic predicates and functions; Ghost and prophecy variables

5. Permissions • Every memory location has an associated permission • A memory location is an (object, field) pair • Permissions can be held by activation records • An activation record is a particular invocation of a method • Permissions can be transferred dynamically • Exhale • Inhale

6. Sharing share thread local shared,available • Objects can be shared new release shared,locked unshare acquire free

7. Monitors share thread local shared,available • An available object can hold permissions • A monitor invariant describes the state of an available object new monitor invariant is checked here release shared,locked unshare acquire free

8. Locking order • Every shared object o is associated with a value o.mu in the locking order • The locking order is a dense lattice, where << denotes its strict partial order • Locks have to be acquired in ascending order • o.mu is set by the share statement • o.mu can be changed by the reorder statement

9. Threads • Fork/join provide asynchronous calls • Roughly: • call o.M() • Exhale Pre; Inhale Post • fork o.M() • Exhale Pre • join o.M() • Inhale Post

10. Abstraction • Predicates provide abstraction • Predicates can also hold permissions • Predicates are opened and closed, usually automatically

11. Fractional permissions • Owicki-Gries example • solution due to Bart Jacobs

12. Example:Hand-over-hand locking :List current tail head :Node :Node :Node :Node

13. Conclusion • Chalice has many features forshared-memory concurrency • Verification via Boogie • Permissions are flexible, but hard to debug with current interface