Looking at external_cgo_thread in output_test.go, there is quite a bit that I don't understand. But I can say that it doesn't look related to the change in CL 220419 (https://go-review.googlesource.com/c/go/+/220419) or the regression it caused (discussion in #42598) and later fixed in 271987 (https://go-review.googlesource.com/c/go/+/271987).

The reason being that CL 220419 and 271987 modify the calls to the data race detector when channels are used to synchronize. Channels are not involved in external_cgo_thread, so the test does not exercise the code paths modified in 220419 and 271987.

I would think that whether the increment to racy++ happens first in the callBack or in main doesn't matter. As far as I understand, the race detector should flag the race regardless. Following this logic, the time.Seep() in main could be placed after the increment to racy++.

The sleep is making sure main does not finish before the callBack() has a chance to run. Is there a way to block until callBack() has run? Blocking would be more bullet-proof than sleeping. We can even add a synchronization here to make sure callBack finishes. I haven't tested this, but something like:

...
var done chan bool
var racy int

//export goCallback
func goCallback() {
  racy++
  done <- true
}

func main() {
  done = make(chan bool)
  var c C.cb
  C.startThread(&c)
  racy++
  <- done
}

@dvyukov , does such a change to the test sound reasonable?

Change https://golang.org/cl/276752 mentions this issue: test: make a race detector test robust to timing variations