Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Pot: Deterministic transactional execution

Tiago Vale
January 24, 2017

Pot: Deterministic transactional execution

Slides presented at HiPEAC 2017.

Reference: Tiago M. Vale, João A. Silva, Ricardo J. Dias, and João M. Lourenço. 2016. Pot: Deterministic Transactional Execution. ACM Trans. Archit. Code Optim. 13, 4.

Paper: https://arxiv.org/pdf/1612.07702

Tiago Vale

January 24, 2017
Tweet

More Decks by Tiago Vale

Other Decks in Research

Transcript

  1. Deterministic transactional execution Tiago Vale1 João Silva1 Ricardo Dias12 João

    Lourenço1 1NOVA LINCS / UNL 2SUSE Linux GmbH
  2. None
  3. read/write read/write

  4. Coordinate operations that access shared state using TM transaction {

    read this do something write that } Only specify what should be atomic, system ensures it!
  5. Coordinate operations that access shared state using TM transaction {

    read this do something write that }
  6. Transactions appear to execute one at a time

  7. Transactions appear to execute one at a time in any

    order = A = B = C
  8. “Heisenbugs”

  9. “Heisenbugs” ~70% of concurrency bugs!* *Learning from mistakes: a comprehensive

    study on real world concurrency bug characteristics, ASPLOS 2008
  10. Fault tolerance = B Replica 1 Replica 2 A ≠

    B = A
  11. Deterministic transaction order helps building reliable concurrent software

  12. “Heisenbugs”

  13. Fault tolerance Replica 1 Replica 2 A = A =

    A = A
  14. Motivation Deterministic transaction execution Evaluation Outline

  15. 2. Commit phase Crash course in TM 1. Speculative phase

  16. y x Shared state 1. Speculative phase

  17. reads writes 1. Speculative phase y x

  18. reads writes read(x) 1. Speculative phase y x

  19. reads writes read(x) 1. Speculative phase y x x

  20. reads writes read(x) write(x) 1. Speculative phase y x x

  21. reads x writes x read(x) write(x) y x 1. Speculative

    phase
  22. reads writes reads writes x x y read(x) write(x) read(x)

    read(y) write(x) y x x x 1. Speculative phase
  23. reads writes Commit read(x) write(x) read(x) read(y) write(x) y x

    x x reads writes x x y 2. Commit phase
  24. read(x) reads write(x) writes read(x) read(y) write(x) x x =

    ? y x x x reads writes x x y 2. Commit phase
  25. read(x) reads write(x) writes read(x) read(y) write(x) y y =

    ? y x x x reads writes x x y 2. Commit phase
  26. read(x) reads write(x) writes read(x) read(y) write(x) y x x

    x reads writes x x y 2. Commit phase
  27. read(x) reads write(x) writes read(x) read(y) write(x) Commit y x

    x x reads writes x x y 2. Commit phase
  28. read(x) reads write(x) writes read(x) read(y) write(x) x x =

    ? y x x x reads writes x x y 2. Commit phase
  29. read(x) reads write(x) writes read(x) read(y) write(x) read(x) write(x) y

    x x x reads writes x x y 1. Speculative phase
  30. read(x) reads write(x) writes read(x) read(y) write(x) read(x) write(x) Commit

    y x x x reads writes x x y 2. Commit phase
  31. read(x) reads write(x) writes read(x) read(y) write(x) read(x) write(x) y

    x x x reads writes x x y 2. Commit phase
  32. read(x) reads write(x) writes read(x) read(y) write(x) read(x) write(x) y

    x x x reads writes x x y 2. Commit phase
  33. Define a deterministic transaction order Guarantee execution respects predefined order

    Key challenges
  34. Sequencer Ordering transactions

  35. Example sequencer Sequencer

  36. Example sequencer Sequencer Replica 1 Replica 2

  37. Define a deterministic transaction order • Sequencer Guarantee execution respects

    predefined order Key challenges
  38. Ordered commits 1 2

  39. Commit? 1 2 Ordered commits

  40. Commit? 1 2 Ordered commits

  41. ZZZ… 1 2 Ȭ Ordered commits

  42. Commit? 1 2 ȭ Ordered commits

  43. Commit? 1 2 ȭ Ordered commits

  44. Hmm? 1 2 Ȯ Ordered commits

  45. Commit! 1 2 Ordered commits

  46. Define a deterministic transaction order • Sequencer Guarantee execution respects

    predefined order • Ordered commits Key challenges
  47. 1 2 3 Fast execution mode

  48. Speculation mechanisms 1 2 3 Fast execution mode

  49. Speculation mechanisms 1 2 3 Fast execution mode

  50. 1 2 3 Fast execution mode

  51. 1 2 3 Fast execution mode

  52. 1 2 3 Fast execution mode

  53. 1 2 3 Fast execution mode

  54. 1 2 3 Fast execution mode

  55. Define a deterministic transaction order • Sequencer Guarantee execution respects

    predefined order • Ordered commits • Fast execution mode Key challenges
  56. Implementation Software TM: • Fast mode: No read set, validation,

    write set, write back
  57. Implementation Software TM: • Fast mode: No read set, validation,

    write set, write back Hardware TM (IBM POWER): • Ordered commits: Suspended transactional mode • Fast mode: Rollback-only transactions See for +details
  58. Motivation Deterministic transaction execution Evaluation Outline

  59. Software transactional memory (see paper for + detail) • Slowdown

    of deterministic execution? • Is the fast execution mode faster? • Do transactions wait less? Hardware transactional memory (see paper) Evaluation See for +details
  60. Normalized execution time 0 1 2 3 4 5 Number

    of threads 2 4 8 16 Deterministic execution (STAMP trend)
  61. Normalized execution time 0 1 2 3 4 5 Number

    of threads 2 4 8 16 Nondeterministic Deterministic execution (STAMP trend)
  62. Normalized execution time 0 1 2 3 4 5 Number

    of threads 2 4 8 16 Nondeterministic This work Deterministic execution (STAMP trend)
  63. Normalized execution time 0 1 2 3 4 5 Number

    of threads 2 4 8 16 Comparable to nondeterministic! Nondeterministic This work Deterministic execution (STAMP trend)
  64. Normalized execution time 0 1 2 3 4 5 Number

    of threads 2 4 8 16 < 2× slower than nondeterministic Nondeterministic This work Deterministic execution (STAMP trend)
  65. Normalized execution time 0 1 2 3 4 5 Number

    of threads 2 4 8 16 Nondeterministic This work State of the art (DeSTM) Deterministic execution (STAMP trend)
  66. Normalized execution time 0 1 2 3 4 5 Number

    of threads 2 4 8 16 Nondeterministic This work State of the art (DeSTM) ~3× better than state of the art! Deterministic execution (STAMP trend)
  67. Evaluation Software transactional memory (see paper for + detail) •

    Slowdown of deterministic execution? • Is the fast execution mode faster? • Do transactions wait less? Hardware transactional memory (see paper) See for +details
  68. Fast mode speedup × faster than standard execution 0 1

    2 3 4 5 6 Number of accesses 0 1 2 4 8 16 32 64
  69. × faster than standard execution 0 1 2 3 4

    5 6 Number of accesses 0 1 2 4 8 16 32 64 50% reads, 50% writes Fast mode speedup
  70. × faster than standard execution 0 1 2 3 4

    5 6 Number of accesses 0 1 2 4 8 16 32 64 Pays off after 2 accesses 50% reads, 50% writes Fast mode speedup
  71. Evaluation Software transactional memory (see paper for + detail) •

    Slowdown of deterministic execution? • Is the fast execution mode faster? • Do transactions wait less? Hardware transactional memory (see paper) See for +details
  72. Waiting overhead (STAMP trend) Normalized time transactions waste waiting 0

    1 2 3 4 Number of threads 2 4 8 16
  73. This work Normalized time transactions waste waiting 0 1 2

    3 4 Number of threads 2 4 8 16 Waiting overhead (STAMP trend)
  74. Normalized time transactions waste waiting 0 1 2 3 4

    Number of threads 2 4 8 16 This work State of the art (DeSTM) Waiting overhead (STAMP trend)
  75. Determinism helps building reliable concurrent software Methodology applicable to both

    STM and HTM Fast mode: take advantage of deterministic order to minimise overheads <2× slower than nondeterministic
 ~3× better than state of the art Conclusion
  76. Determinism helps building reliable concurrent software Methodology applicable to both

    STM and HTM Fast mode: take advantage of deterministic order to minimise overheads <2× slower than nondeterministic
 ~3× better than state of the art Thank you for your attention! Conclusion
  77. Tiago Vale1 João Silva1 Ricardo Dias12 João Lourenço1 1NOVA LINCS

    / UNL 2SUSE Linux GmbH Deterministic transactional execution