On Mon, May 19, 2025 at 10:08 PM Burak Emir <b...@google.com> wrote: > On Mon, May 19, 2025 at 9:01 PM Jann Horn <ja...@google.com> wrote: > > On Mon, May 19, 2025 at 6:24 PM Burak Emir <b...@google.com> wrote: > > > + /// Set bit with index `index`, atomically. > > > + /// > > > + /// ATTENTION: The naming convention differs from C, where the > > > corresponding > > > + /// function is called `set_bit`. > > > + /// > > > + /// # Safety > > > + /// > > > + /// This is a relaxed atomic operation (no implied memory barriers, > > > no > > > + /// ordering guarantees). The caller must ensure that this is safe, > > > as > > > + /// the compiler cannot prevent code with an exclusive reference from > > > + /// calling atomic operations. > > > > How can atomic operations through an exclusive reference be unsafe? > > You can't have a data race between two atomic operations, and an > > exclusive reference should anyway prevent any concurrency, right? > > The atomic operations take a &self (shared reference). > > The patch is missing the implementation of Sync for now. With that, > one would get concurrent write access through shared references. > > The "unsafe" here should serve as reminder to argue why it is ok to > not have any ordering guarantees. > > The last sentence is supposed to say: when you have a &mut bitmap, you > can reborrow it as &bitmap, and then happily call this atomic op. > Even though it is unnecessary.
But using an atomic op when you have a &mut reference is not a safety issue, right? You wrote a comment about behavior with exclusive references in the "# Safety" comment block. If that's not supposed to be a safety problem, this should probably not be in the "# Safety" section?
