[kiitos]

> data races are generals properties of programs that people can and do discuss in language-agnostic contexts

"Data race" is a specific property defined by a memory model, which is normally part of a language spec; it's not usually understood as an abstract property defined in terms of outcome, at least not usefully. If you talk about data races as abstract and language-spec-agnostic properties, then yes, you're assuming a memory model that's shared across all programs and their languages.

[dataflow]

> "Data race" is a specific property defined by a memory model, which is normally part of a language spec; it's not usually understood as an abstract property defined in terms of outcome, at least not usefully.

Really? To me [1] sure doesn't look useless:

> We use the standard definition of a data race: two memory accesses to the same address can be scheduled on different threads to happen concurrently, and at least one of the accesses is a write [16].

You're welcome to look at the [16] it cites, and observe that it is from 1991, entirely in pseudocode, with no mention of a "memory model". It so happens to use the phrase "access anomaly", but evidently that is used synonymously here, per [1].

> If you talk about data races as abstract and language-spec-agnostic properties, then yes, you're assuming a memory model that's shared across all programs and their languages.

No, nobody is assuming such a thing. Different memory models can still exhibit similar properties when analyzing file accesses. Just like how different network models can exhibit similar properties (like queue size bounds, latency, etc.) when discussing network communication. Just because two things are different that doesn't mean they can't exhibit common features you can talk about in a generic fashion.

[1] https://www.cs.columbia.edu/~suman/docs/pla.pdf

[16] https://dl.acm.org/doi/pdf/10.1145/127695.122767

[kiitos]

Java defines what is or isn't a "data race" in one way, as part of its spec. C++ defines that same term "data race" in another way, as part of its spec. Your linked papers use a definition of "data race" which they define themselves based on a claimed 'standard definition' which is different than both the Java and C++ definitions of the same term. The point here is that the definition of "data race" is not universal or objective. When you want to evaluate whether or not some bit of code exhibits a "data race" then without qualifying what you mean when you say "data race" that property is gonna be evaluated in the context of the language, not some higher-level abstract assumption. You can talk about whatever set of common properties of a "data race" that are invariant to language or whatever and that you want to talk about, that's fine, but you need to make that expectation explicit if you want to have a productive conversation with anyone else, because "data race" by itself is context-dependent.