On Mon, 2 Mar 2020 at 18:44, David Laight <David.Laight@xxxxxxxxxx> wrote: > > From: Marco Elver > > Sent: 02 March 2020 14:18 > > > > The definition of "conflict" should not include the type of access nor > > whether the accesses are concurrent or not, which this patch addresses. > > The definition of "data race" remains unchanged. > > > > The definition of "conflict" as we know it and is cited by various > > papers on memory consistency models appeared in [1]: "Two accesses to > > the same variable conflict if at least one is a write; two operations > > conflict if they execute conflicting accesses." > > I'm pretty sure that Linux requires that the underlying memory > subsystem remove any possible 'conflicts' by serialising the > requests (in an arbitrary order). > > So 'conflicts' are never relevant. A "conflict" is nothing bad per-se. A conflict is simply "two accesses to the same location, at least one is a write". Conflicting accesses may not even be concurrent. > There are memory subsystems where conflicts MUST be avoided. > For instance the fpga I use have some dual-ported memory. > Concurrent accesses on the two ports for the same address > must (usually) be avoided if one is a write. > Two writes will generate corrupt memory. > A concurrent write+read will generate a garbage read. > In the special case where the two ports use the same clock > it is possible to force the read to be 'old data' but that > constrains the timings. > > On such systems the code must avoid conflicting cycles. What I gather is that on this system you need to avoid "concurrent conflicting" accesses. Note that, "conflict" does not imply "concurrent" and vice-versa. Thanks, -- Marco
