Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "TM Input Acceptance Vincent Gramoli, Derin Harmanci, Pascal Felber EPFL LPD - University of Neuchâtel Switzerland."— Presentation transcript:

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

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

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 Commit(t1) W(x)_t1StartTx(t1) Commit(t1)W(x)_t1 Workload exampleResulting history DSTM

6 Ensuring history consistency Any transaction aborts (or blocks) if there is any risk of violating consistency Commit(t1) R(x)_t1W(x)_t2StartTx(t1) abort(t2)R(x)_t1W(x)_t2 Another workload example Resulting history DSTM

7 Ensuring history consistency Any transaction aborts (or blocks) if there is any risk of violating consistency Even if consistency would not have been violated! Commit(t1) R(x)_t1W(x)_t2StartTx(t1) abort(t2)R(x)_t1W(x)_t2 DSTM Another workload example Resulting history

8 Ensuring history consistency Commit(t2) Commit(t1) R(x)_t1W(x)_t2StartTx(t1) StartTx(t2) Extended workload Commit(t2) Commit(t1) R(x)_t1W(x)_t2 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 Designs Meaning STM examples VWVR Visible read/write SXM VWIR Visible write Invisible read DSTM, TinySTM IWIR Invisible write Invisible read WSTM, TL2 CTR Commit-time relaxation TSTM RTR Real-time relaxation SSTM

15 Formalizing Workload as an Input Events (i.e., an alphabet): s i : start event of transaction i w x i : write request of transaction i on location x r x i : read request of transaction i on location x π (x) i : any event of transaction i (on location x) c i : 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 = π ∗ (r x i ¬c i ∗ w x j ¬c i ∗ c j | w x j ¬c j ∗ r x i ) π ∗.

17 Generalizing the previous counter-example Theorem. There is no VWIR design that accepts the following input class: C2 = π ∗ (r x i ¬c i ∗ w x j ¬c i ∗ c j | w x j ¬c j ∗ r x i ) π ∗. Commit(t1) R(x)_t1W(x)_t2StartTx(t1)

18 Generalizing the previous counter-example Theorem. There is no VWIR design that accepts the following input class: C2 = π ∗ (r x i ¬c i ∗ w x j ¬c i ∗ c j | w x j ¬c j ∗ r x i ) π ∗. Commit(t1) R(x)_t1W(x)_t2StartTx(t1) The previous workload example is an input pattern belonging to C2

19 Going further Other classes: C 1 = π ∗ (π x i ¬c i ∗ w x j | w x j ¬c j ∗ π x i ) π ∗ C 3 = π ∗ (r x i ¬c i ∗ w x j | w x j ¬c j ∗ r x i ) ¬c i ∗ c j π ∗ C 4 = (¬w x ) ∗ r x i ¬c i ∗ w x j ¬c i ∗ c j ¬c i ∗ s k ¬(c i |c k |r x k ) ∗ w y k ¬(c i |c k | r x k ) ∗ c k ¬c i ∗ r y i π ∗ 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 VWIR (e.g., DSTM, TinySTM) VWVR (e.g. SXM) ~C2 ~C1

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

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

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

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, Derin Harmanci, 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


Download ppt "TM Input Acceptance Vincent Gramoli, Derin Harmanci, Pascal Felber EPFL LPD - University of Neuchâtel Switzerland."

Similar presentations


Ads by Google