1 / 15

Verifying Serializability Considering Only Sequential Executions

Verifying Serializability Considering Only Sequential Executions. Hagit Attiya (Technion) Work in progress with Noam Rinetzky (Tel-Aviv U & Queen Mary) Ganesan Ramalingam (Microsoft Research India) Eran Yahav (IBM Watson). Transactional Synchronization.

Download Presentation

Verifying Serializability Considering Only Sequential Executions

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. Verifying Serializability Considering Only Sequential Executions Hagit Attiya (Technion) Work in progress with Noam Rinetzky (Tel-Aviv U & Queen Mary) Ganesan Ramalingam (Microsoft Research India) Eran Yahav (IBM Watson)

  2. Transactional Synchronization A transaction aggregates a sequence of resource accesses to be executed atomically A sequence of atomic actions A transaction ends either by committing all its updates take effect or by aborting no update is effective Read X Write X Read Z Read Y

  3. (Final State) Serializability [Papadimitriou 79][Weikum, Vossen, 2002, Chapter 3] Any interleaving of the transactions yields a result that could be achieved in some sequential execution of the same set of transactions (a serialization) Just the committed transactions?(Aborted transactions have no effect.)

  4. View Serializability [Yannakakis 1984] • What about intermediate values read? • Could be “corrected” later • But still cause harm, e.g., division by 0 • Any interleaved execution has an equivalent sequential execution • Of the same transactions • Where all reads return the same value

  5. View Serializability: Illustration ~ ~ ~ ~ ~ ~ ~ ~ ~ operation interleaved execution σ0 executions has the same thread-local viewsduring operations σ0 serial execution

  6. Strict Serializability [Papadimitriou 79][Bernstein, Shipman & Wong, 1979] The serialization must preserve the real-time order of (non-overlapping) transactions An analogue of linearizability Called ordered serializabililty in W&V Strict view serializability

  7. Opacity [Guerraoui & Kapalka, PPoPP 08] Essentially, strict view serializability Applied to all transactions (not just committed ones) Generalized to arbitrary object types (not just reads and writes)

  8. Ensuring View Serializability: Two Phase Locking (2PL) • Locking / access rules • All accesses to data items are protected by a lock  no data races • Two phase transactions • growing phase: (acquire(..) | read(…) | write(…))* • shrinking phase: (release(..) | read(…) | write(…))* Theorem:2PL ensures view-serializability [Eswaran et. al., CACM 1976] • In fact, strict view serializability, and even opacity

  9. Ensuring View Serializability: Tree Locking (TL) memory has “the shape of a tree” extensions: semi-trees, forest Locking / access rules every node is protected by a lock “hand-over-hand” traversal down the tree cannot go back to an unlocked node Theorem:TL ensures view serializability [Kedem, Sliberschatz 76; Smadi 76; Bayer, Shckolnick 77] In fact, strict view serializability, and even opacity

  10. How to Ensure 2PL? • Must verify that an application obeys 2PL in all executions • Inspection • Good for simple straightline code • What about complex concurrent libraries? Lock Lx X=1 Unlock Lx If X == 3 then Lock Lz ... Lock Lx X=3 Unlock Lx !@#$%! Hmmm…

  11. Sequentially Observable Locking Policies A locking policy LP is sequentially observable if LP holds in all sequential executions  LP holds in all executions Suffices to verify only that sequential executions ensure LP Slightly weaker property (less useful) LP holds in all non-interleaved executions  LP holds in all executions

  12. Implications • Major reduction in space state that need to be explored • Thread-local verification! • This is what my co-authors care about… • Shape & memory analysis • The memory is a heap • The memory is a collection of linked-lists • No null-dereference • No memory leaks • Termination properties

  13. 2PL is Sequentially Observable Recall the serializability theorem [Papadimitiou ‘86] • operations conflictif they access the same memory location, and one of them writes • serialization graph • nodes: transactions • An edge Ti Tk iff there are conflicting op1 in Ti and op2 in Tk and op1 precedes op2 Theorem: an execution is serializable iff its serialization graph is acyclic

  14. 2PL is Sequentially Observable: “Proof” • Create non-interleaved execution by induction • Only lock operations conflict • Specific properties of locking paradigm • Rely on the serializability of execution prefixes • Then extend to show that it suffices to consider sequential executions

  15. Thank you Questions?

More Related