1 / 7

Thread-local contributions

Thread-local contributions. K. Rustan M. Leino and Peter Müller Microsoft Research. IFIP WG 2.3 meeting 48 22 July 2008 Cambridge, UK. Concurrency framework for verification. Each memory location has a possibly fractional permission for each thread

vilhelm
Download Presentation

Thread-local contributions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Thread-localcontributions K. Rustan M. Leino andPeter Müller Microsoft Research IFIP WG 2.3 meeting 4822 July 2008Cambridge, UK

  2. Concurrency framework for verification • Each memory location has a possibly fractional permission for each thread • Permission = 1  thread can read and write • Permission > 0  thread can read • Can handle readers-writers locks • Locking order can be changed • Can handle algorithms that rebalance trees where each node is locked • Monitors have monitor invariants • Invariant is admissible if monitor has appropriate read permission • Example: invariant CanRead(x)  x < 100; • History constraints (two-state invariants) • Not worked out in detail • Could be used to allow monitor invariants to mention stable conditions, even without read permission • Can aid in rely / guarantee reasoning • Thread contributions…

  3. Owicki and Gries, 1976 { x = 0 } begin var y := 0, z := 0; resource r(x,y,z) invariant x=y+z; cobegin {y=0} lock r do x := x + 1; y := 1 end {y=1} || {z=0} lock r do x := x + 1; z := 1 end {z=1} coend {y=1  z=1  x=y+z} end { x = 2 }

  4. More threads { x = 0 } begin var y: array [0,N) ofint, a: array [0,N) of C; foreachiin [0,N) do y[ i ] := 0; end; share r(x,y) invariant x = ( iin [0,N) :: y[ i ]); foreachiin [0,N) do a[ i ] := new C; a[ i ].k := i; fork a[ i ]; end; foreachiin [0,N) do join a[ i ]; { y[ i ] = 1 } end; unshare r(x,y); end { x = N } class C { var k: int; run() ensures y[k] = old(y)[k] + 1; { lock r do x := x + 1; y[k] := y[k] + 1 end } }

  5. More threads begin var r := new R(); var a: array [0,N) of C; share r; foreachiin [0,N) do a[ i ] := new C; a[ i ].r := r; fork a[ i ]; end; foreachiin [0,N) do join a[ i ]; { a[ i ].y = 1 } end; unshare r; { r.x = N } end class R { var x: int; monitorinvariant x = ( iin [0,N) :: a[ i ].y); } class C { var r: R, y: int := 0; run() ensures y = old(y) + 1; { lock r dor.x := r.x + 1; y := y + 1 end } }

  6. Idea • Programs can only refer to global state and thread-local state of the current thread • Invariants that tie together thread-local state of several threads comes from the methodology

  7. Thread contributions varyglobal: int; for each thread th: varyth: int; class R { var x: int; contributionvar y: int; monitorinvariant x = y; } class C { var r: R; run() ensuresr.y = old(r.y) + 1; { lock r do r.x := r.x + 1; contribute 1; end } } system invariant:yglobal = ( active threads th :: yth) yglobal commutative, associative ytid yglobal := yglobal + 1; ytid := ytid + 1;

More Related