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

Transcript

1. Deterministic transactional execution Tiago Vale1 João Silva1 Ricardo Dias12 João Lourenço1 1NOVA LINCS / UNL 2SUSE Linux GmbH
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