undefined | Better HN

0 pointsdtwwtd13y ago0 comments

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.

0 comments

2 comments · 1 top-level

chubot13y ago· 1 in thread

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.

pcwalton13y ago

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).

j / k navigate · click thread line to collapse