Skip to content
Hallway
0:00 / 0:00

#racedetector#threadsanitizer#vectorclocks

""go test -race" Under the Hood" by Kavya Joshi

Strange Loop Conference

88K subscribers • 110 videos on Hallway • Conference channel

YouTube
  • Recommended by 2 people: 1 in engineering communities and 1 curated list.
  • Presented by Kavya Joshi

Advanced. Deep dive for people who know the field.

10K views10 years ago2 recommendations

Systems programmingProgramming languagesGoConcurrency and parallelismPerformance and optimization

Kavya Joshi explains the compiler instrumentation and runtime algorithms, including vector clocks, used by the Go race detector and ThreadSanitizer.

Writing correct concurrent code is hard. Debugging incorrect concurrent code is even harder. The Go race detector, introduced in Go version 1.1, is one cool tool that makes both easy to do in Go programs. Race conditions are arguably the most elusive programming errors, so how does a tool that detects these across programs operate under the hood? In the case of the Go race detector, with compiler instrumentation of the program and a run-time library that watches for “racy” memory accesses. This talk will delve into the internals of the data race detector — both the instrumentation by the compiler and the happens-before algorithm implemented by the run-time module to detect data races. We will touch upon how the alternative to such a dynamic data race detector — a static data analyzer — differs in design, and the pros and cons of each approach.

Why it's here

2 people recommend this

What people say. Recommended for its deep dive into ThreadSanitizer internals and vector clocks, which are highly relevant to concurrent programming in both Go and C.

u/skeetoin r/C_Programming • Recommends

On “pthreads and data races”

Some background: * Memory Models * How to miscompile programs with “benign” data races * "go test -race" Under the Hood: It's Go, but it goes into TSan internals (vector clocks) and is relevant to C, too. Note that *data races* and *race conditions* are different phenomena. The former can be detected automatically but the latter cannot. Data races are wickedly difficult to reason about in real programs, with non-causal, time travel effects, which is why they're undefined behavior. Synchronization solves data races by ordering concurrent operations. The most common tools are mutexes and atomics, but used incorrectly you may still have a race condition. In your program the only TSan detec…
7View on Reddit

programming-talkscurated list on GitHubRecommends

Under “Go”

"go test -race" Under the Hood 00:44:13 by **Kavya Joshi** (2016)
View the list

u/skeetoin r/C_Programming • Mentions

On “Why this threaded program stops?”

> the program hangs and waits forever By "don't use" I don't mean just delete those lines, but replace them with something sound. The fundamental problem in this case is `pthread_cancel` is not a synchronization point. When it returns, it cancellation request was merely delivered. The thread is still running concurrently, so you're in no position to clean up. The thread still needs to indicate that it's done at a synchronization point. You already have such a function on hand just for this: `pthread_join`. Instead of canceling, put a flag on your queue to indicate that it's done, and make it part of the condition variable check. If the queue is empty and this "done" flag is set, the thread…
2View on Reddit