[RFC v7 3/6] eal: add exactly-once bit access functions
Morten Brørup
mb at smartsharesystems.com
Wed May 8 18:16:59 CEST 2024
> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> Sent: Wednesday, 8 May 2024 17.16
>
> On Wed, 8 May 2024 09:33:43 +0200
> Morten Brørup <mb at smartsharesystems.com> wrote:
>
> > > What more specifically did you have in mind? READ_ONCE() and
> > > WRITE_ONCE()? They give almost no guarantees. Very much relaxed.
> >
> > The way I read it, they do provide memory ordering guarantees.
> >
> > Ignore that the kernel's "once" functions operates on words and this RFC
> operates on bits, the behavior is the same. Either there are memory ordering
> guarantees, or there are not.
>
> The kernel's READ_ONCE/WRITE_ONCE are compiler only ordering, i.e only apply
> to single CPU.
> RTFM memory-barriers.txt..
>
> GUARANTEES
> ----------
>
> There are some minimal guarantees that may be expected of a CPU:
>
> (*) On any given CPU, dependent memory accesses will be issued in order, with
> respect to itself. This means that for:
>
> Q = READ_ONCE(P); D = READ_ONCE(*Q);
>
> the CPU will issue the following memory operations:
>
> Q = LOAD P, D = LOAD *Q
>
> and always in that order.
> However, on DEC Alpha, READ_ONCE() also
> emits a memory-barrier instruction, so that a DEC Alpha CPU will
> instead issue the following memory operations:
>
> Q = LOAD P, MEMORY_BARRIER, D = LOAD *Q, MEMORY_BARRIER
>
> Whether on DEC Alpha or not, the READ_ONCE() also prevents compiler
> mischief.
>
> (*) Overlapping loads and stores within a particular CPU will appear to be
> ordered within that CPU. This means that for:
>
> a = READ_ONCE(*X); WRITE_ONCE(*X, b);
>
> the CPU will only issue the following sequence of memory operations:
>
> a = LOAD *X, STORE *X = b
>
> And for:
>
> WRITE_ONCE(*X, c); d = READ_ONCE(*X);
>
> the CPU will only issue:
>
> STORE *X = c, d = LOAD *X
>
> (Loads and stores overlap if they are targeted at overlapping pieces of
> memory).
It says "*the CPU* will issue the following [sequence of] *memory operations*",
not "*the compiler* will generate the following *CPU instructions*".
To me, that reads like a memory ordering guarantee.
More information about the dev
mailing list