Re: [PATCH v2] tools/memory-model/Documentation: Fix "conflict" definition

[Marco Elver]

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