On Wed, Oct 25, 2023 at 04:02:45PM -0700, Boqun Feng wrote:
[...]
> > > +/// The counter part of C `READ_ONCE()`.
> > > +///
> > > +/// The semantics is exactly the same as `READ_ONCE()`, especially when used for intentional data
> > > +/// races.
> >
> > It would be great if these semantics are either linked or spelled out
> > here. Ideally both.
> >
>
> Actually I haven't found any document about `READ_ONCE()` races with
> writes is not UB: we do have document saying `READ_ONCE()` will disable
> KCSAN checks, but no document says (explicitly) that it's not a UB.
>
Apparently I wasn't carefully reading the doc, in
tools/memory-model/Documentation/explanation.txt, there is:
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 there are two memory accesses such that:
1. they access the same location,
2. at least one of them is a store,
3. at least one of them is plain,
4. they occur on different CPUs (or in different threads on the
same CPU), and
5. they execute concurrently.
the #3 limits that in LKMM, data races cannot happen if both accesses
are marked (i.e. not plain).
Thank Paul for bringing this to me, and I will update this accordingly
in the next version.
Regards,
Boqun
> > > +///
> > > +/// # Safety
> > > +///
> > > +/// * `src` must be valid for reads.
> > > +/// * `src` must be properly aligned.
> > > +/// * `src` must point to a properly initialized value of value `T`.
> > > +#[inline(always)]
> > > +pub unsafe fn read_once<T: Copy>(src: *const T) -> T {
> >
> > Why only `T: Copy`?
> >
[...]
