TM Input Acceptance

Vincent Gramoli, Derin Harmanci, Pascal Felber

EPFL LPD - University of NeuchâtelSwitzerland

How should TM work?

TM

Workload: an input stream of transactional operations

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

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

Ensuring history consistency

• Transactions commit only if consistency cannot be violated

Workload example Resulting history

DSTM

Ensuring history consistency

• Any transaction aborts (or blocks) if there is any risk of violating consistency

Another workload example

Resultinghistory

DSTM

Ensuring history consistency

• Any transaction aborts (or blocks) if there is any risk of violating consistency

• Even if consistency would not have been violated!

DSTM

Another workload example

Resultinghistory

Ensuring history consistency

Extended workload

Resulting history is opaque

Another Performance Metric

• Latency and Throughput are generally benchmark-dependent– difficulty of evaluating the benchmark time overhead

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

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

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)

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?

Identifying TM designs

Designs Meaning STM examples

VWVR Visible read/write

SXM

VWIR Visible writeInvisible read

DSTM, TinySTM

IWIR Invisible writeInvisible read

WSTM, TL2

CTR Commit-time relaxation

TSTM

RTR Real-time relaxation

SSTM

Formalizing Workload as an InputEvents (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”)

Generalizing the previous counter-example

Theorem. There is no VWIR design that accepts the following input class:

C2 = π (r∗ xi ¬ci w∗ x

j ¬ci c∗ j | wxj ¬cj r∗ x

i) π . ∗

Generalizing the previous counter-example

Theorem. There is no VWIR design that accepts the following input class:

C2 = π (r∗ xi ¬ci w∗ x

j ¬ci c∗ j | wxj ¬cj r∗ x

i) π . ∗

Generalizing the previous counter-example

Theorem. There is no VWIR design that accepts the following input class:

C2 = π (r∗ xi ¬ci w∗ x

j ¬ci c∗ j | wxj ¬cj r∗ x

i) π . ∗

The previous workload example is an input pattern belonging to C2

Going furtherOther classes:

C 1 = π (π∗ xi ¬ci w∗ x

j | wxj ¬cj π∗ x

i) π∗C 3 = π (r∗ x

i ¬ci w∗ xj | wx

j ¬cj r∗ xi ) ¬ci c∗ j π ∗

C 4 = (¬wx) r∗ xi ¬ci w∗ x

j ¬ci c∗ j ¬ci s∗ k ¬(ci |ck|rxk) w∗ y

k ¬(ci |ck | rx

k ) c∗ k ¬ci r∗ yi π ∗

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.

Input Acceptance Classification

VWVR(e.g. SXM)

~C1

Input Acceptance Classification

VWIR(e.g., DSTM, TinySTM)

VWVR(e.g. SXM)~C2

~C1

Input Acceptance Classification

IWIR (e.g., WSTMTL2)

VWIR(e.g., DSTM, TinySTM)

VWVR(e.g. SXM)

~C3~C2

~C1

Input Acceptance Classification

CTR(e.g., TSTM)

IWIR (e.g., WSTMTL2)

VWIR(e.g., DSTM, TinySTM)

VWVR(e.g. SXM)

~C4~C3

~C2~C1

Input Acceptance Classification

RTR(e.g., SSTM)

CTR(e.g., TSTM)

IWIR (e.g., WSTMTL2)

VWIR(e.g., DSTM, TinySTM)

VWVR(e.g. SXM)

~C5~C4

~C3~C2

~C1

Serializable STM needs to track all conflicts

Experimental Validation: Scalability

20% Update operations: 10% linked-list insert, 10% linked-list delete80% Other operations: linked-list contains8-core Intel Xeon

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

Thank you

Toward a theory of input acceptance for TMsVincent Gramoli, Derin Harmanci, Pascal Felber

LPD-REPORT-2008-009

http://lpd.epfl.ch/gramoli/doc/pubs/input08.ps

Experimental Validation: Contention

Update operations: 256 elts linked-list insert, deleteOther operations: 256 elts linked-list contains8-core Intel Xeon