Given the code below, I'm trying to understand WHY the Go race detector (go run -race example.go) does not complain about a race condition.
var count int
func main() {
http.HandleFunc("/a/", func(w http.ResponseWriter, r *http.Request) {
count++
fmt.Println(count)
})
http.HandleFunc("/b/", func(w http.ResponseWriter, r *http.Request) {
count++
fmt.Println(count)
})
log.Fatal(http.ListenAndServe(":8080", nil))
}
It's my understanding that the Go HTTP Server responds to all requests in a separate goroutine. With that in mind, would not the increments made to the global count variable by the handler functions happen in a goroutine that is separate from the main goroutine and thus, constitute a data race?
If this is not a data race, I'd very much like to know why.
This is a data race, the race detector however does not report races that don't happen. You need to make sure that there are concurrent calls in your test, and ensuring GOMAXPROCS>1 can help flush them out as well.
count++ is a data race. It does not happen atomically. It is the same as:
count = count + 1
If the race detector doesn't see it, you probably are not hitting the server hard enough.
That's a race condition. False negatives can happen with the race checker.
The race checker is dynamic: rather than checking the source for problems, it only can only see if read and a write actually occur with no sync operation in between. There's no synchronizing operation in your code, but if one occurs in net/http between the increments, it'll be fooled. Its author suggests, essentially, running concurrent stress tests to shake out problems:
- write good concurrent tests
- have continuous build with race detector
- run integration tests
- run race-enabled canaries in production
In Go 1.4 and below, you should also make sure your program runs on more than one core with, e.g., runtime.GOMAXPROCS(runtime.NumCPU()). In Go 1.5, to be released around the end of 2015, GOMAXPROCS will run your code on all available cores by default.