Go Plays Nice With Your Computer --- Race Detection and Freedom!

When we moved from single to multi-processor systems to run our programs faster, we created significant problems for language designers, compiler writers and programmers. Hardware and compiler optimisations can arbitrarily invalidate programs that ran correctly before, and makes the execution dependent on the machine you're running it on, which is not what you want.

To solve this, we need precise definitions of what is expected from compilers and programmers, serving as a contract between them, and a language's memory model provides just that.

What are the optimisations that are allowed by Go compilers and the different hardware? What synchronisation mechanisms are provided by the language? What guarantees does a program without races have? These are questions that are expected to be answered by the Go memory model. We also look at how a Go developer can use existing Go semantics to achieve data race freedom by following simple rules, and achieve the gold standard of consistency models in their code - Sequential Consistency.

Go is also pre-packaged with a Race Detector based on LLVM's TSAN v2, that can help you find pesky race conditions in your code during run-time. We will dive into the internals of it briefly, as well as discuss the new changes the latest TSAN v3 brings! How TSAN managed to improve it's detector drastically will be highlighted in the presentation as this new version was ported to the later versions of Go.

Finally the demo segment of the talk will dive into the buggy examples covered in the Data Race Freedom section, and we will try to see if the race detector can flag these bugs. We will also put TSAN v2 and v3 head to head, profiling them as they race to find these races to look under the hood at what's changed.

Transcript

1. Go Plays Nice With Your Computer Race Detection and Freedom! Raghav Roy
2. whoami
3. Problem
4. We Wanted More Speed
5. Back in the old days … Unhappy with your processor’s performance?
6. Back in the old days … Unhappy with your processor’s performance? Simply wait for an upgrade!
7. Back in the old days … Unhappy with your processor’s performance? Simply wait for an upgrade! “Valid” optimisations = “Valid” Programs
8. Moore, The Party Pooper Trying to run the processor faster doesn't work anymo(o)re
9. Moore, The Party Pooper Trying to run the processor faster doesn't work anymo(o)re Solution?
10. Moore, The Party Pooper Trying to run the processor faster doesn't work anymo(o)re Solution? Mo(o)re Processors!
11. Mo’ Processors, Mo’ Problems
12. Mo’ Processors, Mo’ Problems Breaks the old assumption: Valid optimisations are “invisible”
13. Mo’ Processors, Mo’ Problems Breaks the old assumption: Valid optimisations are “invisible” Valid optimisations for single threads can be “visible” to multi-threaded programs
14. Mo’ Processors, Mo’ Problems
15. Mo’ Processors, Mo’ Problems
16. It depends
17. It depends… Not good
18. It depends The previous example can print 0... but it depends on the hardware.
19. It depends The previous example can print 0... but it depends on the hardware.
20. A World Without Surprises
21. A World Without Surprises --- A Contract
22. Memory Models A memory model is a contract between programmers, compilers, and hardware
23. Memory Models - SC The ideal model is “Sequentially Consistent” (SC).
24. Memory Models - SC The ideal model is “Sequentially Consistent” (SC). The result is the same as some “sequential” execution of operations on a single processor
25. Memory Models - SC The ideal model is “Sequentially Consistent” (SC). The result is the same as some “sequential” execution of operations on a single processor This preserves the order within each thread.
26. Memory Models - SC
27. Memory Models - SC
28. Memory Models - Non-SC
29. What If Programs Could Run As If They Were SC?
30. How Go Gives Us This World
31. Go’s Memory Model Claim: “If your program is free of data races, it will behave as if it's sequentially consistent." – Data Race Free - Sequential Consistency
32. Go’s Memory Model Claim: “If your program is free of data races, it will behave as if it's sequentially consistent." – DRF-SC
33. Go’s Memory Model Claim: “If your program is free of data races, it will behave as if it's sequentially consistent." – DRF-SC
34. Go’s Memory Model Claim: “If your program is free of data races, it will behave as if it's sequentially consistent." – DRF-SC Racy
35. Go’s Memory Model Claim: “If your program is free of data races, it will behave as if it's sequentially consistent." – DRF-SC Synced
36. What is Synchronisation, Really?
37. Ordering Events in a Concurrent World How do we formalize "synchronization"?
38. Ordering Events in a Concurrent World How do we formalize "synchronization"? With the Happens-Before relationship.
39. Ordering Events in a Concurrent World
40. Ordering Events in a Concurrent World
41. Ordering Events in a Concurrent World
42. Ordering Events in a Concurrent World
43. Ordering Events in a Concurrent World
44. We Make Mistakes
45. We Make Mistakes We Write Code That Can Have Data Races
46. The Hero We Need
47. Go’s Race Detector (-race) It watches every memory access to check for conflicting Writes that aren't ordered by a happens-before relationship.
48. Go’s Race Detector (-race)
49. Before We Dive Into The Race Detector
50. Before We Dive Into The Race Detector How Do We Order Events?
51. The Physics of Time (and Code!)
52. How Do We Order Events? To find data races, we need to know if "Event A happened before B". This seems simple
53. How Do We Order Events? To find data races, we need to know if "Event A happened before B". This seems simple, but it's not.
54. How Do We Order Events? To find data races, we need to know if "Event A happened before B". This seems simple, but it's not. We can’t use Physical Clocks – Impossible to perfectly synchronise
55. Time Is A “Partial” Order
56. Time Is A “Partial” Order Every Event Can’t Be Ordered Against Every Other
57. Time Is A “Partial” Order Every Event Can’t Be Ordered Against Every Other No “Total” Order
58. Relativity and Happens-Before • Einstein's big idea: The speed of light is the absolute speed limit for any information.
59. Relativity and Happens-Before • Einstein's big idea: The speed of light is the absolute speed limit for any information. • Minkowski’s big idea: An event can only influence a specific region of space-time around it at a given time.
60. Relativity and Happens-Before
61. Relativity and Happens-Before
62. Relativity and Happens-Before • Anything outside this cone is causally disconnected. It's not in the past, not in the future. It is "Elsewhere".
63. Relativity and Happens-Before
64. Relativity and Happens-Before
65. From Space-Time to Goroutines • As F. Mattern realized, this is a perfect model for distributed systems and concurrent programs!
66. From Space-Time to Goroutines
67. From Space-Time to Goroutines • As F. Mattern realized, this is a perfect model for distributed systems and concurrent programs! • The "speed of light" in Go is the transmission of information
68. From Space-Time to Goroutines • As F. Mattern realized, this is a perfect model for distributed systems and concurrent programs! • The "speed of light" in Go is the transmission of information: a channel send, a mutex unlock, starting a new goroutine.
69. From Space-Time to Goroutines • As F. Mattern realized, this is a perfect model for distributed systems and concurrent programs! • The "speed of light" in Go is the transmission of information: a channel send, a mutex unlock, starting a new goroutine. – Sync Events!
70. Relativity and Happens-Before
71. Relativity and Happens-Before
72. Relativity and Happens-Before
73. Relativity and Happens-Before
74. Relativity and Happens-Before
75. Relativity and Happens-Before
76. Vector Clocks: The Light Cone for Your Code
77. Lamport Clocks
78. Lamport Clocks
79. Lamport Clocks
80. Lamport Clocks
81. Lamport Clocks
82. Lamport Clocks
83. How Do We Find “Elsewhere” Events The Problem: This creates a “total” order
84. The Problem: This creates a “total” order It forces an order on events that might have nothing to do with each other! How Do We Find “Elsewhere” Events
85. The only thing that truly orders events is causality. How Do We Find “Elsewhere” Events
86. The only thing that truly orders events is causality. Could Event A have “Caused” Event B? How Do We Find “Elsewhere” Events
87. Vector Clocks: Under The Hood
88. How The Detector Tracks Causality It's like giving every goroutine its own multi-dimensional clock.
89. How The Detector Tracks Causality It's like giving every goroutine its own multi-dimensional clock. Each goroutine G has a clock array: [C1, C2, C3, ...], one entry per goroutine.
90. How The Detector Tracks Causality It's like giving every goroutine its own multi-dimensional clock. Each goroutine G has a clock array: [C1, C2, C3, ...], one entry per goroutine. When G accesses memory, its own clock CG ticks up.
91. How The Detector Tracks Causality
92. How The Detector Tracks Causality When G1 syncs with G2,
93. How The Detector Tracks Causality When G1 syncs with G2, G2 updates its clock by taking the maximum of its own and G1's clock.
94. How The Detector Tracks Causality
95. How The Detector Tracks Causality
96. How The Detector Tracks Causality
97. How The Detector Tracks Causality
98. How The Detector Tracks Causality
99. How The Detector Tracks Causality We want a race to be detected if a write from G3 is not ordered before/after the last write from G2
100. How The Detector Tracks Causality We want a race to be detected if a write from G3 is not ordered before/after the last write from G2 – Concurrent Writes!
101. How The Detector Tracks Causality We want a race to be detected if a write from G3 is not ordered before/after the last write from G2 – Concurrent Writes! The clocks for W2 and W3 are not ordered – neither is “strictly greater” than the other
102. How The Detector Tracks Causality We want a race to be detected if a write from G3 is not ordered before/after the last write from G2 – Concurrent Writes! The clocks for W2 and W3 are not ordered – neither is “strictly greater” than the other W2:[1,2,0] vs W3:[0,0,2]
103. How The Detector Tracks Causality We want a race to be detected if a write from G3 is not ordered before/after the last write from G2 – Concurrent Writes! The clocks for W2 and W3 are not ordered – neither is “strictly greater” than the other W2:[1,2,0] vs W3:[0,0,2] – Race Detected!
104. How The Detector Tracks Causality Neither Write could have “Caused” the other (within light-speed limits)
105. How The Detector Tracks Causality Neither Write could have “Caused” the other (within light-speed limits)
106. The Upgrade: TSAN v3
107. TSAN v3
108. TSAN v3
109. Minimal Changes To Go (Just a Rebuild)
110. Let’s Put That To The Test
111. Test Goroutine Limit
112. Bench Goroutine Limit
113. Demo Time!
114. Limits Exposed In The Wild
115. Claim
116. Results
117. How Many Goroutines Can TSAN Handle?
118. Go 1.18 Dies At 8128 Goroutines
119. Go 1.19 Keeps Going
120. Overhead Benchmarks: Go 1.18
121. Overhead Benchmarks: Go 1.19 6x Faster
122. CPU Profiles
124. CPU Profile: Go 1.18
125. CPU Profile: Go 1.19 runtime_System: 55.07%
126. Conclusions
127. Conclusions • We can’t always write DRF code --- we need a powerful Race Detector
128. Conclusions • We can’t always write DRF code --- we need a powerful Race Detector • The race detector is awesome, TSAN v3 --- even more so
129. Conclusions • We can’t always write DRF code --- we need a powerful Race Detector • The race detector is awesome, TSAN v3 --- even more so • Vector Clocks model Einsteinian Time --- which is why they work
130. Conclusions • We can’t always write DRF code --- we need a powerful Race Detector • The race detector is awesome, TSAN v3 --- even more so • Vector Clocks model Einsteinian Time --- which is why they work
131. Thank you!
132. References Gopher Credits: Renée French, Tenntenn, egonelbre Speaker Deck: speakerdeck.com/royra