TM Input Acceptance

1. TM Input Acceptance Vincent Gramoli, DerinHarmanci, Pascal Felber EPFL LPD - University of Neuchâtel Switzerland

2. How should TM work? Workload: an input stream of transactional operations TM

3. Model • As opposed to Database systems, read requests of the input must be treated with no delay • All TMs we consider do not wait until conflict resolution (but abort upon conflict detection) • If a transaction aborts, then it must be retried later as a distinct transaction • We consider conflict-serializability

4. History is well-known So far, only history has been formalized • DSTM [HLMS03]is opaque and linearizable • CS-STM [RFSF07] is causal-serializable • TSTM [AA08] is conflict-serializable Meaning that all their histories are consistent

5. Ensuring history consistency • Transactions commit only if consistency cannot be violated DSTM Workload example Resulting history

6. Ensuring history consistency • Any transaction aborts (or blocks) if there is anyrisk of violating consistency DSTM Another workload example Resulting history

7. Ensuring history consistency • Any transaction aborts (or blocks) if there is anyrisk of violating consistency • Even if consistency would not have been violated! DSTM Another workload example Resulting history

8. Ensuring history consistency Extended workload Resulting history is opaque

9. Another Performance Metric • Latency and Throughput are generally benchmark-dependent • difficulty of evaluating the benchmark time overhead

10. Another Performance Metric • Latency and Throughput are generally benchmark-dependent • difficulty of evaluating the benchmark time overhead • Unnecessary aborts: • executing an aborting transaction is a waste (especially long tx) • retrying a transaction may produce additional contention • cascading abort is a well-known issue

11. Another Performance Metric • Latency and Throughput are generally benchmark-dependent • difficulty of evaluating the benchmark time overhead • Unnecessary aborts: • executing an aborting transaction is a waste (especially long tx) • retrying a transaction may produce additional contention • cascading abort is a well-known issue • We should think about other performance metrics • commit-abort ratio “σ”: # committed tx / # complete tx

12. Another Performance Metric • Latency and Throughput are generally benchmark-dependent • difficulty of evaluating the benchmark time overhead • Unnecessary aborts: • executing an aborting transaction is a waste (especially long tx) • retrying a transaction may produce additional contention • cascading abort is a well-known issue • We should think about other performance metrics • commit-abort ratio “σ”: # committed tx / # complete tx • Find new STMs that track conflicts: SSTM (Serializable STM)

13. How do STMs perform w.r.t. this metric? • Ideal goal: no abort (σ = 1) • A TM accepts an input iffσ = 1 • What is accepted by the existing STMs?

14. Identifying TM designs

15. Formalizing Workload as an Input Events (i.e., an alphabet): si: start event of transaction i wxi: write request of transaction i on location x rxi: read request of transaction i on location x π(x)i: any event of transaction i (on location x) ci: commit request of transaction i An input pattern is a totally ordered set of events (i.e., a word) An input class is a set of input patterns (i.e., a language): | represents the choice (e.g., “a | b” means “a” or “b”) * represents the Kleene closure (e.g., “a*” means “ε|a|aa|…”) ¬ represents the complement (e.g., “¬a” means “any event but a”)

16. Generalizing the previous counter-example • Theorem. There is no VWIR design that accepts the following input class: • C2 = π∗ (rxi ¬ci∗ wxj¬ci∗ cj | wxj¬cj∗ rxi) π∗ .

17. Generalizing the previous counter-example • Theorem. There is no VWIR design that accepts the following input class: • C2 = π∗ (rxi ¬ci∗ wxj¬ci∗ cj | wxj¬cj∗ rxi) π∗ .

18. Generalizing the previous counter-example • Theorem. There is no VWIR design that accepts the following input class: • C2 = π∗ (rxi ¬ci∗ wxj¬ci∗ cj | wxj¬cj∗ rxi) π∗ . The previous workload example is an input pattern belonging to C2

19. Going further • Other classes: • C 1 = π∗ (πxi ¬ci∗ wxj | wxj¬cj∗ πxi) π∗ • C 3 = π∗ (rxi ¬ci∗ wxj | wxj ¬cj∗ rxi ) ¬ci∗ cjπ∗ • C 4 = (¬wx)∗ rxi ¬ci∗ wxj ¬ci∗ cj ¬ci∗ sk ¬(ci |ck|rxk)∗ wyk • ¬(ci|ck | rxk )∗ ck ¬ci∗ ryiπ∗ • Other impossibility results: • Theorem 1. VWVR design does not accept input class C1. • Theorem 3. IWIR design does not accept input class C3. • Theorem 4. CTR design does not accept input class C4.

20. Input Acceptance Classification VWVR (e.g. SXM) ~C1

21. Input Acceptance Classification VWVR (e.g. SXM) ~C1 ~C2 VWIR (e.g., DSTM, TinySTM)

22. Input Acceptance Classification IWIR (e.g., WSTM TL2) VWVR (e.g. SXM) ~C1 ~C2 ~C3 VWIR (e.g., DSTM, TinySTM)

23. Input Acceptance Classification IWIR (e.g., WSTM TL2) VWVR (e.g. SXM) ~C1 ~C2 ~C3 ~C4 CTR (e.g., TSTM) VWIR (e.g., DSTM, TinySTM)

24. Input Acceptance Classification Serializable STM needs to track all conflicts IWIR (e.g., WSTM TL2) RTR (e.g., SSTM) VWVR (e.g. SXM) ~C1 ~C2 ~C3 ~C4 ~C5 CTR (e.g., TSTM) VWIR (e.g., DSTM, TinySTM)

25. Experimental Validation: Scalability 20% Update operations: 10% linked-list insert, 10% linked-list delete 80% Other operations: linked-list contains 8-core Intel Xeon

26. Conclusion • Input Acceptance is an important property • Commit-abort ratio is an HW-independent metric • Tradeoff • high input acceptance vs. lightweight implem. • Next Step • Identify all workloads that are not accepted

27. Thank you Toward a theory of input acceptance for TMs Vincent Gramoli, DerinHarmanci, Pascal Felber LPD-REPORT-2008-009 http://lpd.epfl.ch/gramoli/doc/pubs/input08.ps

28. Experimental Validation: Contention Update operations: 256 elts linked-list insert, delete Other operations: 256 elts linked-list contains 8-core Intel Xeon