[intro.races] - C++20 → C++23

Files changed (1) hide show

tmp/tmpb78y62qx/{from.md → to.md} +9 -9

tmp/tmpb78y62qx/{from.md → to.md} RENAMED Viewed

@@ -3,12 +3,12 @@
 The value of an object visible to a thread T at a particular point is
 the initial value of the object, a value assigned to the object by T, or
 a value assigned to the object by another thread, according to the rules
 below.
-[*Note 1*: In some cases, there may instead be undefined behavior. Much
-of this subclause is motivated by the desire to support atomic
 operations with explicit and detailed visibility constraints. However,
 it also implicitly supports a simpler view for more restricted
 programs. — *end note*]
 Two expression evaluations *conflict* if one of them modifies a memory
@@ -41,11 +41,11 @@ All modifications to a particular atomic object M occur in some
 particular total order, called the *modification order* of M.
 [*Note 3*: There is a separate order for each atomic object. There is
 no requirement that these can be combined into a single total order for
 all objects. In general this will be impossible since different threads
-may observe modifications to different objects in inconsistent
 orders. — *end note*]
 A *release sequence* headed by a release operation A on an atomic object
 M is a maximal contiguous sub-sequence of side effects in the
 modification order of M, where the first operation is A, and every
@@ -254,12 +254,12 @@ computation of an object being taken from the last side effect on that
 object in that interleaving. This is normally referred to as “sequential
 consistency”. However, this applies only to data-race-free programs, and
 data-race-free programs cannot observe most program transformations that
 do not change single-threaded program semantics. In fact, most
 single-threaded program transformations continue to be allowed, since
-any program that behaves differently as a result must perform an
-undefined operation. — *end note*]
 Two accesses to the same object of type `volatile std::sig_atomic_t` do
 not result in a data race if both occur in the same thread, even if one
 or more occurs in a signal handler. For each signal handler invocation,
 evaluations performed by the thread invoking a signal handler can be
@@ -275,17 +275,17 @@ potentially shared memory location that would not be modified by the
 abstract machine are generally precluded by this document, since such an
 assignment might overwrite another assignment by a different thread in
 cases in which an abstract machine execution would not have encountered
 a data race. This includes implementations of data member assignment
 that overwrite adjacent members in separate memory locations. Reordering
-of atomic loads in cases in which the atomics in question may alias is
-also generally precluded, since this may violate the coherence
 rules. — *end note*]
 [*Note 23*: Transformations that introduce a speculative read of a
-potentially shared memory location may not preserve the semantics of the
-C++ program as defined in this document, since they potentially
 introduce a data race. However, they are typically valid in the context
 of an optimizing compiler that targets a specific machine with
 well-defined semantics for data races. They would be invalid for a
 hypothetical machine that is not tolerant of races or provides hardware
 race detection. — *end note*]

 The value of an object visible to a thread T at a particular point is
 the initial value of the object, a value assigned to the object by T, or
 a value assigned to the object by another thread, according to the rules
 below.
+[*Note 1*: In some cases, there might instead be undefined behavior.
+Much of this subclause is motivated by the desire to support atomic
 operations with explicit and detailed visibility constraints. However,
 it also implicitly supports a simpler view for more restricted
 programs. — *end note*]
 Two expression evaluations *conflict* if one of them modifies a memory
 particular total order, called the *modification order* of M.
 [*Note 3*: There is a separate order for each atomic object. There is
 no requirement that these can be combined into a single total order for
 all objects. In general this will be impossible since different threads
+can observe modifications to different objects in inconsistent
 orders. — *end note*]
 A *release sequence* headed by a release operation A on an atomic object
 M is a maximal contiguous sub-sequence of side effects in the
 modification order of M, where the first operation is A, and every
 object in that interleaving. This is normally referred to as “sequential
 consistency”. However, this applies only to data-race-free programs, and
 data-race-free programs cannot observe most program transformations that
 do not change single-threaded program semantics. In fact, most
 single-threaded program transformations continue to be allowed, since
+any program that behaves differently as a result has undefined
+behavior. — *end note*]
 Two accesses to the same object of type `volatile std::sig_atomic_t` do
 not result in a data race if both occur in the same thread, even if one
 or more occurs in a signal handler. For each signal handler invocation,
 evaluations performed by the thread invoking a signal handler can be
 abstract machine are generally precluded by this document, since such an
 assignment might overwrite another assignment by a different thread in
 cases in which an abstract machine execution would not have encountered
 a data race. This includes implementations of data member assignment
 that overwrite adjacent members in separate memory locations. Reordering
+of atomic loads in cases in which the atomics in question might alias is
+also generally precluded, since this could violate the coherence
 rules. — *end note*]
 [*Note 23*: Transformations that introduce a speculative read of a
+potentially shared memory location might not preserve the semantics of
+the C++ program as defined in this document, since they potentially
 introduce a data race. However, they are typically valid in the context
 of an optimizing compiler that targets a specific machine with
 well-defined semantics for data races. They would be invalid for a
 hypothetical machine that is not tolerant of races or provides hardware
 race detection. — *end note*]

Diff to HTML by rtfpessoa