[concurrency-interest] On A Formal Definition of 'Data-Race'
brian at briangoetz.com
Tue Apr 16 18:18:46 EDT 2013
> The "how do you know this program is thread-safe"?
> "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