Correct Concurrency with Chalice

Rustan LeinoRiSE, Microsoft Research, Redmond

MIT5 June 2009

Joint work with:Peter Müller, ETH ZurichJan Smans, KU Leuven

Some textbook conceptsAtomicity

Sequential reasoning within atomic sections

Monitor invariantsAssumed when monitor is acquiredChecked when monitor is released

Locking orderDeadlock prevention

Rely-guarantee reasoningThread interference

class Cell { int val; invariant val > 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; } } }}

ChallengesClient-side locking

One monitor protects lots of state

Fine-grained lockingOne field protected by several monitors

Thread-local and shared objects

Transitions in both directions

Dynamic changes of locking order

class Node { int val; Node next; invariant next null

val next.val;

… }

class List { Node head; void Reverse( ) { … } … }

ChaliceExperimental language with focus on:

Share-memory concurrencyStatic verification

Key featuresMemory access governed by a model of permissionsSharing via locks with monitor invariantsDeadlock checking, dynamic lock re-ordering

Other featuresClasses; 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

PermissionsEvery 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

ExhaleInhale

SharingObjects can be shared

thread local

shared,availabl

e

shared,locked

new

share

acquire

release

unshare

free

MonitorsAn available object can hold permissionsA monitor invariant describes the state of an available object

thread local

shared,availabl

e

shared,locked

new

share

acquire

release

unshare

free

monitor invariant is checked here

Locking orderEvery shared object o is associated with a value o.mu in the locking orderThe locking order is a dense lattice, where << denotes its strict partial orderLocks have to be acquired in ascending ordero.mu is set by the share statemento.mu can be changed by the reorder statement

ThreadsFork/join provide asynchronous callsRoughly:

call o.M()Exhale Pre; Inhale Post

fork o.M()Exhale Pre

join o.M()Inhale Post

AbstractionPredicates provide abstractionPredicates can also hold permissionsPredicates are opened and closed, usually automatically

Fractional permissionsOwicki-Gries example

solution due to Bart Jacobs

Example:

Hand-over-hand locking

:List

:Node :Node :Node :Node

head

tailcurrent

ConclusionChalice has many features forshared-memory concurrencyVerification via BoogiePermissions are flexible, but hard to debug with current interface