Modern Concurrent Separation Logics Philippa Gardner Thomas Pedro da Rocha Pinto Dinsdale-Young Resource Reasoning 2016 1 / 37
Counter Module function read ( x ) { function incr ( x ) { function wkincr ( x ) { do { r := [ x ]; r := [ x ]; return r ; r := [ x ]; [ x ] := r + 1; } b := CAS ( x , r , r + 1); } } while ( b = 0); return r ; } 2 / 37
Ticket Lock Client function lock ( x ) { function unlock ( x ) { t := incr ( x . next ); wkincr ( x . owner ); do { } v := read ( x . owner ) } while ( v � = t ); } 3 / 37
Sequential Specification Abstract predicate C ( x , n ) describes a counter with value n ∈ N at address x . { C ( x , n ) } read ( x ) { C ( x , n ) ∧ ret = n } { C ( x , n ) } incr ( x ) { C ( x , n + 1) ∧ ret = n } { C ( x , n ) } wkincr ( x ) { C ( x , n + 1) } Pros: The specification captures sequential behaviour. Cons: The specification does not support concurrency. 4 / 37
Specification of Concurrent Modules Modular specifications of concurrent modules require: ◮ auxiliary state: Owicki, Gries ◮ interference abstraction: Jones ◮ resource ownership: O’Hearn ◮ atomicity: Herlithy Peter Maurice Herlihy O’Hearn Cliff Jones Susan Owicki David Gries 5 / 37
Specification of Concurrent Modules Modular specifications of concurrent modules require: ◮ auxiliary state ◮ interference abstraction ◮ resource ownership ◮ atomicity 6 / 37
Auxiliary State: Owicki-Gries Parallel Rule { P 1 } C 1 { Q 1 } { P 2 } C 2 { Q 2 } non-interference { P 1 ∧ P 2 } C 1 � C 2 { Q 1 ∧ Q 2 } 7 / 37
Auxiliary State: Owicki-Gries Concurrent Specification using Invariants {∃ n. C ( x , n ) } read ( x ) {∃ n, m. C ( x , n ) ∧ ret = m } {∃ n. C ( x , n ) } incr ( x ) {∃ n, m. C ( x , n ) ∧ ret = m } {∃ n. C ( x , n ) } wkincr ( x ) {∃ n. C ( x , n ) } Pros: The specification captures concurrent behaviour. Cons: Using invariants leads to very weak specifications. No information about the actual value of the counter. 8 / 37
Auxiliary State: Owicki-Gries Stronger specifications require auxiliary state: � � C ( x , 0) y := 0; z := 0; � � C ( x , 0) ∧ y = 0 ∧ z = 0 � � � � C ( x , y + z ) ∧ y = 0 C ( x , y + z ) ∧ z = 0 do { do { r ′ := [ x ]; r := [ x ]; � b ′ := CAS ( x , r ′ , r ′ + 1); � b := CAS ( x , r , r + 1); if ( b ) y++ ; � if ( b ′ ) z++ ; � } while ( b ′ = 0); } while ( b = 0); � � � � C ( x , y + z ) ∧ y = 1 C ( x , y + z ) ∧ z = 1 � � C ( x , 2) ∧ y = 1 ∧ z = 1 � � C ( x , 2) 9 / 37
Auxiliary State: Owicki-Gries Pros: The specification is strong. Cons: The proof method, introducing auxiliary code, is not modular. 10 / 37
Auxiliary State: Owicki-Gries Auxiliary state, introduced in the Owicki-Gries method, is important for specifying concurrent modules. 11 / 37
Specification of Concurrent Modules Modular specifications of concurrent modules require: ◮ auxiliary state ◮ interference abstraction ◮ resource ownership ◮ atomicity 12 / 37
Interference Abstraction: Rely/guarantee Parallel Rule The R s and G s are called rely and guarantee relations respectively. � � � � � � � � R ∪ G 2 , G 1 ⊢ R ∪ G 1 , G 2 ⊢ P 1 C 1 Q 1 P 2 C 2 Q 2 � � � � R, G 1 ∪ G 2 ⊢ P 1 ∧ P 2 C 1 � C 2 Q 1 ∧ Q 2 13 / 37
Interference Abstraction: Rely/guarantee Specification: read ( x ) and incr ( x ) A, ∅ ⊢ {∃ n. C ( x , n ) } read ( x ) {∃ n. C ( x , n ) ∧ ret ≤ n } A, A ⊢ {∃ n. C ( x , n ) } incr ( x ) {∃ n. C ( x , n ) ∧ ret ≤ n } where A = { C ( x , n ) � C ( x , n + 1) | n ∈ N } . Pros: The behaviour that the environment might do is specified. Cons: This specification does not restrict the increment operation to perform a single increment. 14 / 37
Ticket Lock Client function lock ( x ) { function unlock ( x ) { t := incr ( x . next ); wkincr ( x . owner ); do { } v := read ( x . owner ) } while ( v � = t ); } 15 / 37
Interference Abstraction: Rely/guarantee Specification: wkincr ( x ) ∃ n ′ ≥ n + 1 . C ( x , n ′ ) R, G ⊢ � � � � C ( x , n ) wkincr ( x ) where R = { C ( x , m ) � C ( x , m + 1) | m > n } and G is as before. Pros: This specification allows weak increments to occur concurrently. Cons: This specification is too weak to reason about the ticket lock. 16 / 37
Interference Abstraction: Rely/guarantee Interference abstraction, introduced in the rely/guarantee method, is important for specifying concurrent modules. 17 / 37
Specification of Concurrent Modules Modular specifications of concurrent modules require: ◮ auxiliary state ◮ interference abstraction ◮ resource ownership ◮ atomicity 18 / 37
Resource Ownership: Concurrent Separation Logics Parallel Rule The disjoint concurrency rule from concurrent separation logic: { P 1 } C 1 { Q 1 } { P 2 } C 2 { Q 2 } { P 1 ∗ P 2 } C 1 � C 2 { Q 1 ∗ Q 2 } Ownership embodies specialised notions of auxiliary state and interference abstraction. If a thread owns a resource, then the environment cannot manipulate it. 19 / 37
Resource Ownership: Concurrent Separation Logics Fractional Permissions C ( x , n 1 + n 2 , π 1 + π 2 ) ⇐ ⇒ C ( x , n 1 , π 1 ) ∗ C ( x , n 2 , π 2 ) for n 1 , n 2 ∈ N and π 1 , π 2 ∈ (0 , 1] and π 1 + π 2 ≤ 1 . The abstract predicate C ( x , n, π 1 ) now means that this resource contributes value n to the counter at x with permission π 1 . 20 / 37
Resource Ownership: Concurrent Separation Logics Specification using Fractional Permissions { C ( x , n, π ) } read ( x ) { C ( x , n, π ) ∧ ret ≥ n } { C ( x , n, 1) } read ( x ) { C ( x , n, 1) ∧ ret = n } { C ( x , n, π ) } incr ( x ) { C ( x , n + 1 , π ) ∧ ret ≥ n } { C ( x , n, 1) } wkincr ( x ) { C ( x , n + 1 , 1) } Pros: This specification allows concurrent reads and increments. Cons: The specification enforces sequential weak increments. The return values are no longer guaranteed to be the actual value of the counter. 21 / 37
Resource Ownership: Concurrent Separation Logics � � C ( x , 0 , 1) � � C ( x , 0 , 0 . 5) ∗ C ( x , 0 , 0 . 5) � � � � C ( x , 0 , 0 . 5) C ( x , 0 , 0 . 5) incr ( x ) incr ( x ) � � � � C ( x , 1 , 0 . 5) C ( x , 1 , 0 . 5) � � C ( x , 1 , 0 . 5) ∗ C ( x , 1 , 0 . 5) � � C ( x , 2 , 1) 22 / 37
Resource Ownership: Concurrent Separation Logics Resource ownership, developed by concurrent separation logic and its successors, is important for specifying concurrent modules. 23 / 37
Specification of Concurrent Modules Modular specifications of concurrent modules require: ◮ auxiliary state ◮ interference abstraction ◮ resource ownership ◮ atomicity 24 / 37
Atomicity Atomicity provides a way to abstract interference. It gives the abstraction that an operation takes effect at a single, discrete instant in time. 25 / 37
Atomicity: Linearisability Sequential Specification for read ( x ) and incr ( x ) { C ( x , n ) } read ( x ) { C ( x , n ) ∧ ret = n } { C ( x , n ) } incr ( x ) { C ( x , n + 1) ∧ ret = n } Pros: Strong concurrent reasoning about read ( x ) and incr ( x ) . Cons: Linearisability does not allow us to control the interference like rely-guarantee. 26 / 37
Atomicity: Linearisability Sequential Specification with wkincr ( x ) not possible { C ( x , n ) } read ( x ) { C ( x , n ) ∧ ret = n } { C ( x , n ) } incr ( x ) { C ( x , n + 1) ∧ ret = n } { C ( x , n ) } wkincr ( x ) { C ( x , n + 1) } Cons: The wkincr is not atomic when other increments occur. 27 / 37
Atomicity: Linearisability Atomicity, put forward by linearisability, is important for specifying concurrent modules. 28 / 37
Synthesis Now we combine auxiliary state, interference abstraction, resource reasoning and atomicity to provide expressive specifications for concurrent modules. 29 / 37
Synthesis ◮ higher-order: Birkedal, Dreyer, Jacobs, Turon ◮ history-based: Nanevski, Sergey ◮ first-order: da Rocha Pinto, Dinsdale-Young, Gardner Ilya Sergey Aaron Turon Bart Jacobs Aleks Nanevski Derek Dreyer Lars Birkedal 30 / 37
Synthesis: First-order Approach A simple atomic triple has the form A x ∈ X. � P ( x ) � C � Q ( x ) � 31 / 37
Synthesis: First-order Approach Specification using Atomic Triples n. � C ( s, x , n ) � read ( x ) � C ( s, x , n ) ∧ ret = n � A n. � C ( s, x , n ) � incr ( x ) � C ( s, x , n + 1) ∧ ret = n � A � C ( s, x , n ) � wkincr ( x ) � C ( s, x , n + 1) � Pros: Atomic triples specify operations with respect to an abstraction; each operation can be verified independently. The specification is strong. It allows concurrent reads and concurrent increments, and concurrent reads and one weak increment. 32 / 37
Verfication of Implementations and Clients Verification of the counter implementation. Specification and verification of the ticket-lock client. Pros: A specification of ticket lock whose implementation is based on the atomic counter commands. Cons: The specification of ticket lock is not atomic. It requires helping (on-going). 33 / 37
Recommend
More recommend
