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

thurstonn thurston at nomagicsoftware.com
Wed Apr 17 01:54:09 EDT 2013


Brian Goetz-3 wrote
>> 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?

Uh, yes.


Brian Goetz-3 wrote
> 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. 

I addressed this specifically in an earlier response:
"Yes, there is an assumption in my OP that "data-race" ==> "incorrect" (or
"broken logic" in your words)
Vitaly does not necessarily equate "raciness" with "incorrectness" (and
probably Brian as well) and that's OK with me"

I'm not sure how I can be clearer than that.
Although I wouldn't describe what I'm after as a "formal notion of mt
correctness" - but that's probably just a quibble.
I'm not sure that all responses that have defined a data-race have given the
exact same "precise meaning", but regardless I'm *not* hung-up on the term
"data-race", I think it makes sense to use the most conservative definition
(conflicting operations from multiple threads) which allows for the notion
of a "benign" data-race


Brian Goetz-3 wrote
> 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), 

Hmm, let me quote:
"A program that accesses a mutable variable from multiple threads without
synchronization is a broken program" -- sound familiar?
Clearly String#hashCode() qualifies, and yet all agree that it *is*
"correct"







--
View this message in context: http://jsr166-concurrency.10961.n7.nabble.com/On-A-Formal-Definition-of-Data-Race-tp9408p9472.html
Sent from the JSR166 Concurrency mailing list archive at Nabble.com.


More information about the Concurrency-interest mailing list