Ser ializability of T r ansac tions in Softwar e T r ansac - - PowerPoint PPT Presentation

▶
ser ializability of t r ansac tions in softwar e t r
SMART_READER_LITE
LIVE PREVIEW

Ser ializability of T r ansac tions in Softwar e T r ansac - - PowerPoint PPT Presentation

Dec 07, 2022 198 likes •549 views

Ser ializability of T r ansac tions in Softwar e T r ansac tional Memor y Utku Aydonat Utku Aydonat uaydonat@eecg.toronto.edu De partme nt o f E le c tric al and Co mpute r E ngine e ring U nive rsity o f T o ro nto Workshop on

slide-1
SLIDE 1

Ser ializability of T r ansac tions in Softwar e T r ansac tional Memor y

Utku Aydonat Utku Aydonat

uaydonat@eecg.toronto.edu

De partme nt o f E le c tric al and Co mpute r E ngine e ring U nive rsity o f T

  • ro nto

Workshop on Transactional Computing (TRANSACT) Workshop on Transactional Computing (TRANSACT) 2008 2008

slide-2
SLIDE 2

Outline

  • Motivation

– STM systems perform poorly for some applications.

  • 2-Phase Locking

– Why can it be an overly conservative technique?

  • Conflict Serializability

– What is the advantage of conflict-serializability?

  • Ensuring Conflict-Serializability

– How can we implement conflict-serializability efficiently?

  • Multi-Versioning
  • Experimental Evaluation
  • Conclusions

2

slide-3
SLIDE 3

Motivation

  • Short transactions with low data sharing

– Successful STM implementations (blocking STMs, time-based STMs, etc.) – Aborts are insignificant for performance.

  • For RBT, the abort rate is 0.23% at 32 threads, avg. tx. time is 11 µsec.
  • Throughput:

bench=RBTREE workload=1:1:1 200000 400000 600000 800000 1000000 1200000 1400000 1600000 1800000 1 6 11 16 21 26 31 threads throughput

CG RSTM

3

slide-4
SLIDE 4

Motivation

  • Long transactions with high data sharing

– Popular STM implementations suffer in performance. – Abort rates impact the performance.

  • For LL, the abort rate is 79% at 32 threads, avg. tx. time is 197 µsec.
  • Throughput:

bench=LL workload=1:1:1 5000 10000 15000 20000 25000 1 6 11 16 21 26 31 threads throughput

CG RSTM

4

slide-5
SLIDE 5

Consistency in STMs

  • Are STMs too eager to abort transactions?
  • Linearizability: Correctness criteria for STMs.

– Transactions appear to execute atomically at some point between their start time and commit time.

TX1 TX2 TX3 time

5

slide-6
SLIDE 6

Consistency in STMs

  • Are STMs too eager to abort transactions?
  • Linearizability: Correctness criteria for STMs.

– Transactions appear to execute atomically at some point between their start time and commit time.

TX1 TX2 TX3 TX2 TX3 time

Equivalent sequential execution!

6

slide-7
SLIDE 7

Consistency in STMs

  • Are STMs too eager to abort transactions?
  • Linearizability: Correctness criteria for STMs.

– Transactions appear to execute atomically at some point between their start time and commit time.

TX1 TX2 TX3 TX2 TX3 TX1 time

Equivalent sequential execution!

7

slide-8
SLIDE 8

Consistency in STMs

  • Are STMs too eager to abort transactions?
  • Linearizability: Correctness criteria for STMs.

– Transactions appear to execute atomically at some point between their start time and commit time.

TX1 TX2 TX3 TX2 TX3 TX1 TX1 time

Equivalent sequential execution!

8

slide-9
SLIDE 9

Consistency in STMs

  • Are STMs too eager to abort transactions?
  • Linearizability: Correctness criteria for STMs.

– Transactions appear to execute atomically at some point between their start time and commit time.

TX1 TX2 TX3 TX2 TX3 TX1 TX1 TX1 time

Equivalent sequential execution!

9

slide-10
SLIDE 10

Two Phase Locking

  • STMs emulate two phase locking (2PL) to ensure

linearizability.

– Conflicting accesses are not allowed from the access time till the transaction commits. – More conservative than linearizability. – Easy to implement: fast transactions but frequent aborts.

ObjA ObjB ObjC ObjD

TX1 TX1

time

R W W R R W TX2 TX2

10

slide-11
SLIDE 11

Two Phase Locking

  • STMs emulate two phase locking (2PL) to ensure

linearizability.

– Conflicting accesses are not allowed from the access time till the transaction commits. – More conservative than linearizability. – Easy to implement: fast transactions but frequent aborts.

ObjA ObjB ObjC ObjD

TX1 TX1

time

R W W R R W TX2 TX2

Delay or Abort!

11

slide-12
SLIDE 12

Two Phase Locking

  • STMs emulate two phase locking (2PL) to ensure

linearizability.

– Conflicting accesses are not allowed from the access time till the transaction commits. – More conservative than linearizability. – Easy to implement: fast transactions but frequent aborts.

ObjA ObjB ObjC ObjD

TX1 TX1 R W W R R W TX2 TX2

12

TX1 TX2

equivalent seq. exec.

slide-13
SLIDE 13

Conflict-Serializability (CS)

13

  • Allows conflicting accesses as long as we can find a valid
  • rdering for transactions; an ordering that matches the order
  • f conflicting accesses.
  • More relax than 2PL & linearizability.

ObjA ObjB ObjC ObjD ObjE

TX1 TX2 TX3

equivalent seq. exec. W W R W W R W TX1 TX1 TX2 TX2 TX3 TX3

slide-14
SLIDE 14

Conflict Serializability (CS)

  • Conclusion: We can reduce abort rates in STMs by

implementing CS rather than 2PL.

  • We can build a precedence/ordering/serializability graph.

– Too slow

  • We use Serializability Order Numbers (SONs)

14

slide-15
SLIDE 15

Serializability Order Numbers (SONs)

  • Each transaction gets a SON number when it commits.
  • The order of SON numbers matches the order of conflicting

accesses for all transactions.

– Rule1: If TX1 accesses an object committed by TX2 SON(TX1) > SON(TX2) – Rule2: If TX2 commits an object already read by TX1 SON(TX2) > SON(TX1)

  • Keep an SON range for each active transaction [lb, ub]

– Assign SON number based on lb & ub, such that lb < SON < ub – If up < lb at any point, transaction cannot be serialized.

TX1 TX2 TX3

equivalent seq. exec.

15

slide-16
SLIDE 16

Serializability Order Numbers (SONs)

[0:∞] Start TX2; [0:∞] Start TX3; [0:∞] Start TX1;

time

Equivalent sequential execution!

16

slide-17
SLIDE 17

Serializability Order Numbers (SONs)

[0:∞] Start TX3; . [0:∞] Write(B); [0:∞] Start TX2; [0:∞] Read(B); . [0:∞] Start TX1; [0:∞] Read(A); .

time

Equivalent sequential execution!

17

slide-18
SLIDE 18

Serializability Order Numbers (SONs)

[0:∞] Start TX3; . [0:∞] Write(B); Commit; [0:∞] Start TX2; [0:∞] Read(B); . [0:∞] Start TX1; [0:∞] Read(A); .

time

Equivalent sequential execution!

18

slide-19
SLIDE 19

Serializability Order Numbers (SONs)

[0:∞] Start TX3; . [0:∞] Write(B); SON=3 Commit; [0:∞] Start TX2; [0:∞] Read(B); . [0:∞] Start TX1; [0:∞] Read(A); .

time

SON=3

TX3

Equivalent sequential execution!

19

slide-20
SLIDE 20

Serializability Order Numbers (SONs)

[0:∞] Start TX3; . [0:∞] Write(B); SON=3 Commit; [0:∞] Start TX2; [0:∞] Read(B); . [0:3] [0:∞] Start TX1; [0:∞] Read(A); . .

time

TX3

SON=3

TX2

Equivalent sequential execution!

20

slide-21
SLIDE 21

Serializability Order Numbers (SONs)

[0:∞] Start TX3; . [0:∞] Write(B); SON=3 Commit; [0:∞] Start TX2; [0:∞] Read(B); . [0:3] [0:3] Write(A); Commit; [0:∞] Start TX1; [0:∞] Read(A); . . .

time

TX3

SON=3

TX2

Equivalent sequential execution!

21

slide-22
SLIDE 22

Serializability Order Numbers (SONs)

[0:∞] Start TX3; . [0:∞] Write(B); SON=3 Commit; [0:∞] Start TX2; [0:∞] Read(B); . [0:3] [0:3] Write(A); SON=2 Commit; [0:∞] Start TX1; [0:∞] Read(A); . . .

time

SON=2 SON=3

TX3 TX2

Equivalent sequential execution!

22

slide-23
SLIDE 23

Serializability Order Numbers (SONs)

[0:∞] Start TX3; . [0:∞] Write(B); SON=3 Commit; [0:∞] Start TX2; [0:∞] Read(B); . [0:3] [0:3] Write(A); SON=2 Commit; [0:∞] Start TX1; [0:∞] Read(A); . . . [0:2]

time

TX3 TX2

SON=2

TX1

SON=3

Equivalent sequential execution!

23

slide-24
SLIDE 24

Serializability Order Numbers (SONs)

[0:∞] Start TX3; . [0:∞] Write(B); SON=3 Commit; [0:∞] Start TX2; [0:∞] Read(B); . [0:3] [0:3] Write(A); SON=2 Commit; [0:∞] Start TX1; [0:∞] Read(A); . . . [0:2] Read(B);

time

TX3 TX2

SON=2

TX1

SON=3

Equivalent sequential execution!

24

slide-25
SLIDE 25

Serializability Order Numbers (SONs)

[0:∞] Start TX3; . [0:∞] Write(B); SON=3 Commit; [0:∞] Start TX2; [0:∞] Read(B); . [0:3] [0:3] Write(A); SON=2 Commit; [0:∞] Start TX1; [0:∞] Read(A); . . . [0:2] [3:2] Read(B);

time

TX3 TX2

SON=2 SON=3

TX1 TX1

Equivalent sequential execution!

25

slide-26
SLIDE 26

Serializability Order Numbers (SONs)

[0:∞] Start TX3; . [0:∞] Write(B); SON=3 Commit; [0:∞] Start TX2; [0:∞] Read(B); . [0:3] [0:3] Write(A); SON=2 Commit; [0:∞] Start TX1; [0:∞] Read(A); . . . [0:2] [3:2] Read(B); Abort;

time

TX3 TX2

SON=2 SON=3

TX1 TX1

Equivalent sequential execution!

26

slide-27
SLIDE 27

Multi-Versioning

  • If reading the latest version of data cannot be

serialized, perhaps reading an older version can be.

– Keep older versions for each object. – Update SON ranges based on the version read.

  • Avoids having to reject operations that arrive to late

to be serializable.

27

slide-28
SLIDE 28

Toronto STM (TSTM)

  • Implements CS with multi-versioning.
  • C++, Object-based, indirection with wrappers, obstruction-

free, visible readers.

  • High overheads

– Accessing SON ranges. – Iterating reader transactions. – Pays off when aborts are important.

  • Adaptive TSTM

– Switches consistency model based on abort rates: CS vs. 2PL

28

slide-29
SLIDE 29

Experimental Evaluation

  • Platform: Sun-Fire 15K, 72 UltraSPARCIII 1.2 GHz proc.

– Use only 32 processors. – Single thread per processor, no nested transactions.

  • Benchmarks:

– LinkedList (LL), RB Tree (RBT), Graph (GR). – Workload: 1:1:1 insert/delete/lookup. – Value ranges: 16K(LL), 64K(RBT), 4K(GR).

  • Evaluated algorithms:

– Fine-grain locking (FG), Coarse-grain locking (CG). – TSTM, TSTM-adaptive. – RSTM, TL2.

29

slide-30
SLIDE 30

LinkedList

throughput vs. threads

5000 10000 15000 20000 25000 1 6 11 16 21 26 31 CG FG T L2 R ST M T ST M T ST M

  • adaptive

30

slide-31
SLIDE 31

LinkedList

% aborts vs. threads

10 20 30 40 50 60 70 80 90 100 1 6 11 16 21 26 31

TSTM

  • 2PL

TSTM

  • CS

RSTM

31

slide-32
SLIDE 32

RBT

throughput vs. threads

500000 1000000 1500000 2000000 2500000 3000000 3500000 4000000 4500000 1 6 11 16 21 26 31

CG FG TL2 RSTM TSTM TSTM

  • adaptive

32

slide-33
SLIDE 33

Related Work

33

  • Early Release & Open Nesting & Collection Classes

–

  • M. Herlihy, V. Luchangco, M. Moir, and I. William N. Scherer, “Software transactional memory for

dynamic-sized data structures,”in Proc. of PODC, pp. 92–101, 2003. –

  • Y. Ni, V. S. Menon, A.-R. Adl-Tabatabai, A. L. Hosking, R. L. Hudson, J. E. B. Moss, B. Saha, and
  • T. Shpeisman, “Open nesting in software transactional memory,” in Proc. of PPoPP, pp. 68–78,

2007. –

  • B. D. Carlstrom, A. McDonald, M. Carbin, C. Kozyrakis, and K. Olukotun, “Transactional collection

classes,” in In Prof. of PPoPP, pp. 56–67, 2007.

  • Snapshot Isolation

–

  • T. Riegel, P. Felber, and C. Fetzer, “A lazy snapshot algorithm with eager validation,” in

Proceedings of the 20th International Symposium on Distributed Computing, DISC 2006, vol. 4167,

  • pp. 284–298, Sep 2006.
  • Z-linearizability

–

  • T. Riegel, H. Sturzrehm, P. Felber, and C. Fetzer, “From causal to z-linearizable transactional

memory,” Tech. Rep. RR-I-07-02.1, Universite de Neuchatel, Institut d’Informatique, Feb 2007.

  • Databases

–

  • J. Lindstrom and K. Raatikainen, “Dynamic adjustment of serialization order using timestamp

intervals in real-time DBMS,” in Proc. of the Int’l Conf. on Real-Time Computing Systems and Applications, 1999.

slide-34
SLIDE 34

Conclusions

  • 2PL is too restrictive for applications with long transactions

and high data sharing.

  • CS gives better performance despite its high overheads

– 2.5 times better throughput for LL. – 4 times better throughput for GR.

  • Poor performance for applications with short transactions
  • Dynamically adapting the model yields the best performance
  • We need to look into more models

– Is adapting between several different models viable?

34