Re: [PATCH v15 1/7] rust: sync: add `SetOnce`

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"Benno Lossin" <lossin@xxxxxxxxxx> writes:

> On Tue Jul 8, 2025 at 10:54 AM CEST, Andreas Hindborg wrote:
>> "Boqun Feng" <boqun.feng@xxxxxxxxx> writes:
>>
>>> On Mon, Jul 07, 2025 at 03:38:58PM +0200, Alice Ryhl wrote:
>>>> On Mon, Jul 7, 2025 at 3:32 PM Andreas Hindborg <a.hindborg@xxxxxxxxxx> wrote:
>>>> >
>>>> > Introduce the `SetOnce` type, a container that can only be written once.
>>>> > The container uses an internal atomic to synchronize writes to the internal
>>>> > value.
>>>> >
>>>> > Signed-off-by: Andreas Hindborg <a.hindborg@xxxxxxxxxx>
>>>>
>>>> LGTM:
>>>> Reviewed-by: Alice Ryhl <aliceryhl@xxxxxxxxxx>
>>>>
>>>> > +impl<T> Drop for SetOnce<T> {
>>>> > +    fn drop(&mut self) {
>>>> > +        if self.init.load(Acquire) == 2 {
>>>> > +            // SAFETY: By the type invariants of `Self`, `self.init == 2` means that `self.value`
>>>> > +            // contains a valid value. We have exclusive access, as we hold a `mut` reference to
>>>> > +            // `self`.
>>>> > +            unsafe { drop_in_place(self.value.get()) };
>>>>
>>>> This load does not need to be Acquire. It can be a Relaxed load or
>>>> even an unsynchronized one since the access is exclusive.
>>>
>>> Right, I think we can do the similar as Revocable here:
>>>
>>>         if *self.init.get_mut() == 2 { }

Ok, now I got it. You are saying I don't need to use the atomic load
method, because I have mutable access. Sounds good.

But I guess a relaxed load and access through a mutable reference should
result in the same code generation on most (all?) platforms?

>>>
>>> Further, with my following Benno's suggestion and making `Atomic<T>` an
>>> `UnsafeCell<T>:
>>>
>>> 	https://lore.kernel.org/rust-for-linux/aGhh-TvNOWhkt0JG@xxxxxxxx/
>>>
>>> compiler can generate a noalias reference here, which allows further
>>> optimization.
>>>
>>
>> You would like to remove `PhantomPinned` to enable noalias? I guess that
>> makes sense in this case. I'll fix that for next spin.
>
> I think you two are talking about different things. Boqun is saying that
> the `Atomic<T>` will use `UnsafeCell` rather than `Opaque`, which will
> potentially allow more optimizations.
>
> But you are talking about `SetOnce`, right? I think it makes more sense
> for `SetOnce` to use `UnsafeCell<MaybeUninit<T>>` rather than `Opaque`
> too. So feel free to change it in the next version.

Exactly. We don't need `UnsafePinned` mechanics here.


Best regards,
Andreas Hindborg








[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux