Optimistic Methods for Concurrency Controlx Yumin Pan 2020107

  • Slides: 14
Download presentation
Optimistic Methods for Concurrency Controlx Yumin Pan 2020/10/7 EECS 584, Fall 2009 1

Optimistic Methods for Concurrency Controlx Yumin Pan 2020/10/7 EECS 584, Fall 2009 1

Contents n Validation phase n Validation conditions n Transaction numbers n Serial validation n

Contents n Validation phase n Validation conditions n Transaction numbers n Serial validation n Parallel validation 2020/10/7 EECS 584, Fall 2009 2

Concurrency n Definition: computations running simulta neously, and potentially interacting with each other. n

Concurrency n Definition: computations running simulta neously, and potentially interacting with each other. n Transactions should executed serial. n Two methods to ensure we get the desired result – Locking – Optimistic Concurrency control 2020/10/7 EECS 584, Fall 2009 3

Optimistic Concurrency control n Reading phase n Validation phase n Write Phase

Optimistic Concurrency control n Reading phase n Validation phase n Write Phase

Validation phase n If inconsistency detected, roll back and redo the computation in some

Validation phase n If inconsistency detected, roll back and redo the computation in some other sequence, and “hope” this time everything will be fine. n Otherwise, we go on. n How can we tell the transaction is inconsistent?

Inconsistency Transaction n Account A transfer $100 to Account B n Account A transfer

Inconsistency Transaction n Account A transfer $100 to Account B n Account A transfer $100 to Account C Read Balance A $100 Account C Account B Write Balance A-100 Balance A reduced by 100 Correct

Serial Equivalence n A criterion to verify the correctness of execution of transactions n

Serial Equivalence n A criterion to verify the correctness of execution of transactions n T: transaction n D: set of all possible result

Validation conditions 1 n Two transaction A, B are consistent – Assume A starts

Validation conditions 1 n Two transaction A, B are consistent – Assume A starts earlier than B n If one finished before another starts B A

Validation conditions 2 n If the write of the A didn’t influence the read

Validation conditions 2 n If the write of the A didn’t influence the read of B. n And the B won’t overwrite the result of the A before A finishes. A B A

Validation conditions 3 n The write of A won’t influence the read and write

Validation conditions 3 n The write of A won’t influence the read and write of B. n And A finishes read before B finishes read B A

Transaction numbers n Using a counter (tnc) to distinguish different transactions n We assign

Transaction numbers n Using a counter (tnc) to distinguish different transactions n We assign this number at the end of the read phase. n Ensure condition 3 is always valid

Serial validation n Implementation of condition 1 and 2 n To ensure atomicity –

Serial validation n Implementation of condition 1 and 2 n To ensure atomicity – Before a transaction write back – We check whether the write sets of transactions between start tn to finish tn intersects its read set – The whole check should be atomic and be protected by locks n To minimize the critical section, we can move some work to valid part

Parallel validation n Use all three conditions n Assign transaction number after the write

Parallel validation n Use all three conditions n Assign transaction number after the write phase if validation succeeds. n To implement condition 3 – Introduce the active set – Add transaction id to active set after read phase – Check whether the write sets of active set intersects the read or write set of the current transaction

Thank You ! 2020/10/7 EECS 584, Fall 2009 14

Thank You ! 2020/10/7 EECS 584, Fall 2009 14