[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87cyaboypx.fsf@kernel.org>
Date: Tue, 08 Jul 2025 10:47:54 +0200
From: Andreas Hindborg <a.hindborg@...nel.org>
To: "Alice Ryhl" <aliceryhl@...gle.com>
Cc: "Miguel Ojeda" <ojeda@...nel.org>, "Alex Gaynor"
<alex.gaynor@...il.com>, "Boqun Feng" <boqun.feng@...il.com>, "Gary Guo"
<gary@...yguo.net>, Björn Roy Baron
<bjorn3_gh@...tonmail.com>,
"Masahiro Yamada" <masahiroy@...nel.org>, "Nathan Chancellor"
<nathan@...nel.org>, "Luis Chamberlain" <mcgrof@...nel.org>, "Danilo
Krummrich" <dakr@...nel.org>, "Benno Lossin" <lossin@...nel.org>,
"Nicolas Schier" <nicolas.schier@...ux.dev>, "Trevor Gross"
<tmgross@...ch.edu>, "Adam Bratschi-Kaye" <ark.email@...il.com>,
<rust-for-linux@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<linux-kbuild@...r.kernel.org>, "Petr Pavlu" <petr.pavlu@...e.com>,
"Sami Tolvanen" <samitolvanen@...gle.com>, "Daniel Gomez"
<da.gomez@...sung.com>, "Simona Vetter" <simona.vetter@...ll.ch>, "Greg
KH" <gregkh@...uxfoundation.org>, "Fiona Behrens" <me@...enk.dev>,
"Daniel Almeida" <daniel.almeida@...labora.com>,
<linux-modules@...r.kernel.org>
Subject: Re: [PATCH v15 1/7] rust: sync: add `SetOnce`
"Alice Ryhl" <aliceryhl@...gle.com> writes:
> On Mon, Jul 7, 2025 at 3:32 PM Andreas Hindborg <a.hindborg@...nel.org> 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@...nel.org>
>
> LGTM:
> Reviewed-by: Alice Ryhl <aliceryhl@...gle.com>
>
>> +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, that is actually very cool. My rationale was that if a reference
has been shared to another thread of execution, we would need to
synchronize here to see a possible initialization from that other
thread. But I guess it is impossible to end the lifetime of a reference
without doing a synchronization somewhere else.
Best regards,
Andreas Hindborg
Powered by blists - more mailing lists