Re: [PATCH v5 04/10] rust: sync: atomic: Add generic atomics

Andreas Hindborg
2025-06-30T09:52:47Z

"Boqun Feng" <boqun.feng@gmail.com> writes:

> On Thu, Jun 26, 2025 at 02:15:35PM +0200, Andreas Hindborg wrote:
>> "Boqun Feng" <boqun.feng@gmail.com> writes:
>>
>> [...]
>>
>> > +
>> > +impl<T: AllowAtomic> Atomic<T> {
>> > + /// Creates a new atomic.
>> > + pub const fn new(v: T) -> Self {
>> > + Self(Opaque::new(v))
>> > + }
>> > +
>> > + /// Creates a reference to [`Self`] from a pointer.
>> > + ///
>> > + /// # Safety
>> > + ///
>> > + /// - `ptr` has to be a valid pointer.
>> > + /// - `ptr` has to be valid for both reads and writes for the whole lifetime `'a`.
>> > + /// - For the whole lifetime of '`a`, other accesses to the object cannot cause data races
>> > + /// (defined by [`LKMM`]) against atomic operations on the returned reference.
>>
>> I feel the wording is a bit tangled here. How about something along the
>> lines of
>>
>> For the duration of `'a`, all accesses to the object must be atomic.
>>
>
> Well, a non-atomic read vs an atomic read is not a data race (for both
> Rust memory model and LKMM), so your proposal is overly restricted.

OK, my mistake then. I thought mixing marked and plain accesses would be
considered a race. I got hat from
`tools/memory-model/Documentation/explanation.txt`:

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.

I did not study all that documentation, so I might be missing a point or
two.

Best regards,
Andreas Hindborg