correctness(criteria(for( concurrency(&(...
TRANSCRIPT
CORRECTNESS CRITERIA FOR CONCURRENCY & PARALLELISM
6/16/2010 Correctness Criteria for Parallelism & Concurrency 1
Contracts – Correctness for SequenGal Code
6/16/2010 Correctness Criteria for Parallelism & Concurrency 2
Contracts – Correctness for SequenGal Code
• AsserGons • A predicate expected to hold at a parGcular program point
• PrecondiGon • A predicate expected to hold at a funcGon call • A failure can be blamed on the caller
• PostcondiGon • A predicate expected to hold at a funcGon return • A failure can be blamed on the callee
6/16/2010 Correctness Criteria for Parallelism & Concurrency 3
int Divide(int n, int d) { return n/d; }
Code Contracts for .Net
6/16/2010 Correctness Criteria for Parallelism & Concurrency 4
int Divide(int n, int d) { Contract.Requires( 0 != d ); return n/d; }
PrecondiGons using Requires
6/16/2010 Correctness Criteria for Parallelism & Concurrency 5
int Divide(int n, int d) { Contract.Requires( 0 != d ); Contract.Ensures( Contract.Result<int>() * d <= n && Contract.Result<int>() * d > n-‐d );
return n/d; }
PrecondiGons using Ensures
6/16/2010 Correctness Criteria for Parallelism & Concurrency 6
Example: Library APIs
6/16/2010 Correctness Criteria for Parallelism & Concurrency 7
Example: System Call API
6/16/2010 Correctness Criteria for Parallelism & Concurrency 8
Correctness for Concurrency & Parallelism
• Reuse contracts wriQen for sequenGal code
• Relate correctness of concurrent/parallel execuGons to correctness of appropriate sequenGal execuGons
6/16/2010 Correctness Criteria for Parallelism & Concurrency 9
Coin SorGng Example
Vending Machine Sort Coins
accept reject
6/16/2010 Correctness Criteria for Parallelism & Concurrency 10
Use Contracts for Correctness Criteria
• SortCoins accepts a set of coins and returns a set of bad ones • Parallelizing SortCoins should not change the contract
SortCoins(…) { Contract.Requires(…); Contract.Ensures(…);
}
SequenGal ImplementaGon
SortCoins(…) { Contract.Requires(…); Contract.Ensures(…);
}
Parallel ImplementaGon
6/16/2010 Correctness Criteria for Parallelism & Concurrency 11
Parallelizing can someGmes produce correct but different outputs
SequenIal SortCoins
accept reject
Parallel SortCoins
accept reject
The order of coins can change
6/16/2010 Correctness Criteria for Parallelism & Concurrency 12
RestricGve Contracts Can Limit Parallelism
• The order of coins returned by SortCoins might be different from the input order • Do care about the total amount returned
• If the contracts enforce the ordering, resulGng parallelizaGon might be unacceptably slow • Design interfaces in such a way that contracts are not restricGve
6/16/2010 Correctness Criteria for Parallelism & Concurrency 13
Strategies For Reasoning About Parallel Code
• How do we know if a parallel loop saGsfies its contract? • Reasoning about parallel execuGons is hard
General Strategy: 1. Make sure that every parallel behavior is equal to
some sequenGal behavior
2. Convince that the sequenGal behavior saGsfies the contract
6/16/2010 Correctness Criteria for Parallelism & Concurrency 14
Independent Loops
• Let m(1) … m(n) be the loop iteraGons
• Two iteraGons m(j) and m(k) (j ≠ k) are dependent if they access the same memory locaGon and at least one of them is a write.
• Loop iteraGons are independent if no two of them are dependent
6/16/2010 Correctness Criteria for Parallelism & Concurrency 15
Dependent Loops
• Dependencies need to be made explicit • No data races
• Reason that order of dependent operaGons don’t maQer • e.g. These operaGons are commutaGve and associaGve
• Recall: reduce/scan
6/16/2010 Correctness Criteria for Parallelism & Concurrency 16
Determinism: A New Correctness Criteria • Pre and post condiGons do two things • Specify how the funcGon behaves sequenGally • Enforce the same behavior when parallelized
int ComputeSum ( IEnumerable<int> input) { Contract.Requires ( input != null);
Contract.Ensures ( Contract.Result<int>() == input.Sum(i => i) ));
//implementation }
6/16/2010 Correctness Criteria for Parallelism & Concurrency 17
Determinism Contract
• Allows you to check parallel correctness • Without having to specify the sequenGal contract • The output of the funcGon does not depend on task interleavings for a given input
int ComputeSum ( IEnumerable<int> input) { Contract.Requires ( input != null);
IsDeterministic ( Contract.Result<int>(), input );
//implementation }
6/16/2010 Correctness Criteria for Parallelism & Concurrency 18
Determinism Checking
Is same as saying
For some determinisGc funcGon F
Very useful when specifying F is tedious
Contract.IsDeterministic ( output, {input1, input2, … })
Contract.Ensures ( output == F ( input1, input2, … ) )
6/16/2010 Correctness Criteria for Parallelism & Concurrency 19
Determinism Checking
Is same as saying
For some determinisGc funcGon F
Contract.IsDeterministic ( output, {input1, input2, … }, comp)
Contract.Ensures ( comp(output, F ( input1, input2, … ) )
6/16/2010 Correctness Criteria for Parallelism & Concurrency 20
Strategies for Checking Determinism
6/16/2010 Correctness Criteria for Parallelism & Concurrency 21
Concurrent Objects
• Can be called concurrently by many threads
• Examples • Work Stealing Queue
6/16/2010 Correctness Criteria for Parallelism & Concurrency 22
Concurrent Objects
• Can be called concurrently by many enGGes
• Examples • Work Stealing Queue • C RunGme library
• OperaGng System
• Data bases
6/16/2010 Correctness Criteria for Parallelism & Concurrency 23
Correctness Criteria
• Informally called “thread safety”
• What does “thread safety” mean to you?
6/16/2010 Correctness Criteria for Parallelism & Concurrency 24
A Simple Concurrent Object
• SequenGal Queue • Add(item) • TryTake() returns an item or “empty”
• Size() returns # of items in queue
• Consider ConcurrentQueue and its relaGonship to Queue
6/16/2010 Correctness Criteria for Parallelism & Concurrency 25
Let’s Write a Test
q = new ConcurrentQueue();
q.Add(10) t=q.TryTake()
Assert( ? )
q = new ConcurrentQueue();
q.Add(10) t=q.TryTake()
Assert: q.Size() is 0 or 1
Let’s Write a Test
q = new ConcurrentQueue();
q.Add(10); t=q.TryTake();
Assert: t = fail && q.size() = 1 || t = 10 && q.size() = 0
Let’s Write a Test
q = new ConcurrentQueue();
q.Add(10) t=q.TryTake()
q.Add(20) u = q.TryTake()
Assert ( ? )
Let’s Write a Test
q = new ConcurrentQueue();
Assert: q.Size() == 0
t = 10 || t = 20 u = 10 || t = 20
u != t
q.Add(10) t=q.TryTake()
q.Add(20) u = q.TryTake()
Let’s Write a Test
Linearizability • The correctness noGon closest to “thread safety”
• A concurrent component behaves as if only one thread can enter the component at a Gme
6/16/2010 Correctness Criteria for Parallelism & Concurrency 31
“Expected” Behavior?
Client 1
Client 2
Client 3
Add 10 return Add 20 return
TryTake return10
TryTake return “empty”
6/16/2010 Correctness Criteria for Parallelism & Concurrency 32
“Expected” Behavior?
Client 1
Client 2
Client 3
Add 10 return Add 20 return
TryTake return10
TryTake return “empty”
Client 1
Client 2
Client 3
Add 10 return
Add 20 return
TryTake return20
TryTake return “empty”
6/16/2010 Correctness Criteria for Parallelism & Concurrency 33
Linearizability • Component is linearizable if all operaGons • Appear to take effect atomically at a single temporal point • And that point is between the call and the return
• “As if the requests went to the queue one at a Gme”
Client 1
Client 2
Client 3
Add 10 return Add 20 return
TryTake return10
TryTake return “empty”
6/16/2010 Correctness Criteria for Parallelism & Concurrency 34
Linearizability vs Seriazliability? • Serializability • All operaGons (transacGons) appear to take effect atomically at a single temporal point
6/16/2010 Correctness Criteria for Parallelism & Concurrency 35
Linearizability vs Seriazliability? • Serializability • All operaGons (transacGons) appear to take effect atomically at a single temporal point
• Linearizability • All operaGons to take effect atomically at a single temporal point
• That point is between the call and return
6/16/2010 Correctness Criteria for Parallelism & Concurrency 36
Serializable behavior that is not Linearizable
• Linearizability assumes that there is a global observer that can observe that Thread 1 finished before Thread 2 started
Thread 1
Thread 2
Add 10 return
TryTake return “empty”
6/16/2010 Correctness Criteria for Parallelism & Concurrency 37
Serializability does not compose
• The behavior of the blue queue and green queue are individually serializable • But, together, the behavior is not serializable
Thread 1
Thread 2
Add 10 return
TryTake return “empty” Add 10 return
TryTake return “empty”
6/16/2010 Correctness Criteria for Parallelism & Concurrency 38
Formalizing Linearizability
• Define the set of observables for each operaGon • Call operaGon: value of all the arugments • Return operaGon:
• An event: • Thread Id, Object Id, Call/Return, OperaGon, Observables
6/16/2010 Correctness Criteria for Parallelism & Concurrency 39
Add 10 return
A Concurrent History
• Sequence of Events • <T1, q, Call, Add, 10> • <T2, q, Call, TryTake, void> • <T1, q, Ret, Add, void> • <T2, q, Ret, TryTake, “empty”>
6/16/2010 Correctness Criteria for Parallelism & Concurrency 40
Thread 1
Thread 2
Add 10 return
TryTake return “empty”
A Concurrent History
• Sequence of Events • <T1, q, Call, Add, 10> • <T2, q, Call, TryTake, void> • <T1, q, Ret, Add, void> • <T2, q, Ret, TryTake, “empty”>
6/16/2010 Correctness Criteria for Parallelism & Concurrency 41
Thread 1
Thread 2
Add 10 return
TryTake return “empty”
We will only focus on single object histories
A Concurrent History
• Sequence of Events • <T1, q, Call, Add, 10> • <T2, q, Call, TryTake, void> • <T1, q, Ret, Add, void> • <T2, q, Ret, TryTake, “empty”>
6/16/2010 Correctness Criteria for Parallelism & Concurrency 42
Thread 1
Thread 2
Add 10 return
TryTake return “empty”
Also, we will only focus on complete histories – every call has a return
A Serial History
• A concurrent history where every call is followed by its matching return • <T1, q, Call, Add, 10> • <T1, q, Ret, Add, void> • <T2, q, Call, TryTake, void> • <T2, q, Ret, TryTake, “empty”>
6/16/2010 Correctness Criteria for Parallelism & Concurrency 43
Thread 1
Thread 2
Add 10 return
TryTake return “empty”
SequenGal SpecificaGon of an Object
• The set of all serial histories define the sequenGal behavior of an object
• Assume we have a mechanism to enumerate this set and store the set in a database
6/16/2010 Correctness Criteria for Parallelism & Concurrency 44
Equivalent Histories
• Two concurrent histories are equivalent if • Each thread performs operaGons in the same order • And sees the same observaGons
6/16/2010 Correctness Criteria for Parallelism & Concurrency 45
Client 1
Client 2 Add 10 return Add 20 return
TryTake return10
Client 1
Client 2 Add 10 return Add 20 return
TryTake return10
Concurrent OperaGons in a History
• Two operaGons p and q are concurrent in a history if their duraGon overlap • ! (p.ret < q.call || q.ret < p.call)
6/16/2010 Correctness Criteria for Parallelism & Concurrency 46
Thread 1
Thread 2
Add 10 return
TryTake return “empty”
Concurrent OperaGons in a History
• Two operaGons p and q are concurrent in a history if their duraGon overlap • ! (p.ret < q.call || q.ret < p.call)
• Non-‐Concurrent operaGons define a “performed-‐before” order
6/16/2010 Correctness Criteria for Parallelism & Concurrency 47
Client 1
Client 2 Add 10 return Add 20 return
TryTake return10
Linearizability
• A concurrent history is linearizable if it is equivalent to a (serial) history in the sequenGal specificaGon,
• Such that all operaGons that are “performed before” in the concurrent history are also “performed before” in the serial history
6/16/2010 Correctness Criteria for Parallelism & Concurrency 48
6/16/2010 Correctness Criteria for Parallelism & Concurrency 49