On Mon, Jul 15, 2013 at 3:12 AM, Brendan Tracey wrote:
The race detector blog post says "It will not issue false positives, so take
its warnings seriously". Is it also true that the race detector doesn't
issue false negatives? I'm told that in the general case race detection is
related to the halting problem, but since it is analyzing running code it
seems like this shouldn't actually be an issue. I'm having some strange
issues with my concurrent code, and this code passes the race detector. I'm
wondering if this means I can rule out a race condition. Thanks.
Yes, formally the race detector is false-negative-free. But there are
2 points to it:
1. As others pointed out, there are implementation issues and possible
bugs, e.g. some memory accesses may be non-instrumented and invisible
to the race detector. I would say that it's currently (on tip) in a
quite good shape.
However, false positives are highly visible. While false negatives are
usually invisible. So if you will track the problem and will turn out
to be a missed race, please report it. Such reports are invaluable.
2. The definition of "false-negative-free" is not what an end user may
expect it to be. An end user may expect "is my program race free?".
While the race detector answers -- "is this particular of a program is
Do not assume that the program is race-free is the race detector is silent.
Run the program with the race detector under different workloads and
different values of GOMAXPROCS.
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firstname.lastname@example.org.
For more options, visit https://groups.google.com/groups/opt_out.