[Cowen]

I'll paraphrase something Andrew Gerrand said about this at a golang meetup last night:

Because race conditions are so hard to detect, the race detector is obviously prone to false negatives. Just because the tester doesn't find any race conditions doesn't necessarily mean that there aren't any. But the race detector never finds false positives. If it finds a race condition, that condition is very real.

You could just run your app with the race detector on all the time, but there is a performance cost to using the race detector.

One way to get around this in cloud/clustered environments is to deploy your app on a few machines with the race detector on and the rest with the race detector off. That way you're running your app with a production load and you're more likely to find race conditions, but you'll mitigate the performance costs associated with the race detector.

[dtwwtd]

It makes sense to me that it can't possibly detect all race conditions but I had never really thought about the ability to detect any race conditions programmatically.

Running the detector on just a few nodes sounds like a great way to offset the performance penalty a bit. The docs on the race detector say that "memory usage may increase by 5-10x and execution time by 2-20x" which could be quite significant.

I also wonder about the effectiveness of randomly fuzzing your app with the race detector on as a form of testing.

[chubot]

I'll take a bet that detecting ALL race conditions is equivalent to the halting problem.

Certainly for an entire program it is... not sure if you limit it to the just the code paths executed.

[pcwalton]

It will always be inexact. All dynamic analyses of this type are, because they only observe what the program does as it executes and do not enforce any restrictions.

If you want a more guaranteed form of race freedom, you need to constrain what programs can do, either with dynamic restrictions on mutable state sharing (like Erlang or the parallel extensions to JavaScript do) or with a type system strong enough to reason about sharing of data (like Haskell or Rust).