For language-level memory consistency models that are adaptations of data-race-free, the definition of "data race" can be summarized as "concurrent conflicting accesses, where at least one is non-sync/plain". The definition of "conflict" should not include the type of access nor whether the accesses are concurrent or not, which this patch addresses for explanation.txt. The definition of "data race" remains unchanged, but the informal definition for "conflict" is restored to what can be found in the literature. Signed-by: Marco Elver <elver@xxxxxxxxxx> --- tools/memory-model/Documentation/explanation.txt | 15 ++++++--------- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/tools/memory-model/Documentation/explanation.txt b/tools/memory-model/Documentation/explanation.txt index e91a2eb19592a..11cf89b5b85d9 100644 --- a/tools/memory-model/Documentation/explanation.txt +++ b/tools/memory-model/Documentation/explanation.txt @@ -1986,18 +1986,15 @@ violates the compiler's assumptions, which would render the ultimate outcome undefined. In technical terms, the compiler is allowed to assume that when the -program executes, there will not be any data races. A "data race" -occurs when two conflicting memory accesses execute concurrently; -two memory accesses "conflict" if: +program executes, there will not be any data races. A "data race" +occurs if: - they access the same location, + two concurrent memory accesses "conflict"; - they occur on different CPUs (or in different threads on the - same CPU), + and at least one of the accesses is a plain access; - at least one of them is a plain access, - - and at least one of them is a store. + where two memory accesses "conflict" if they access the same + memory location, and at least one performs a write; The LKMM tries to determine whether a program contains two conflicting accesses which may execute concurrently; if it does then the LKMM says -- 2.25.1.481.gfbce0eb801-goog
