[concurrency-interest] On A Formal Definition of 'Data-Race'

Brian Goetz brian at briangoetz.com
Tue Apr 16 18:18:46 EDT 2013

> The "how do you know this program is thread-safe"?
> Pause.
> "I thought *really* hard about it"
> I can't be the only one who finds that deeply unsatisfying

Is *this* really your question?

You have been asking about data races, which is a term that has a 
precise meaning, and you got lots of precise answers about data races -- 
none of which were what you were looking for, because really, I think 
what you're asking for is a formal notion of multithreaded correctness. 
  Which, in a system which embraces mutable-by-default, is not all that 
realistic a wish.

Further, data races and thread-safety are not even ordered with respect 
to each other; there are racy programs that are still correct (the 
benign data race in String.hashCode() is a fine example), and there are 
non-thread-safe programs that have no data races.  Data-race-freedom is 
neither necessary nor sufficient for multithreaded correctness -- though 
it is a pretty good start.

We all find the situation deeply unsatisfying, but this is the real 
world, and experiments in taking away mutable-by-default from mainstream 
programmers have not been all that successful.  So we do what we can 
within the world we live in and the systems people choose to program in. 
  (I spent quite a lot of time and effort writing a book trying to 
capture good practices that reduce people's chances of writing bad code. 
  The fact that I couldn't make it impossible for people to write bad 
code, or even force everyone to read it, didn't deter me.)

More information about the Concurrency-interest mailing list