[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <45395395-9bbe-4ee8-9a4f-f1890cd85752@gmail.com>
Date: Fri, 9 Feb 2024 16:27:38 -0300
From: Martin Rodriguez Reboredo <yakoyoku@...il.com>
To: Mathys Gasnier <mathys35.gasnier@...il.com>,
Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>,
Wedson Almeida Filho <wedsonaf@...il.com>, Boqun Feng
<boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
Björn Roy Baron <bjorn3_gh@...tonmail.com>,
Benno Lossin <benno.lossin@...ton.me>,
Andreas Hindborg <a.hindborg@...sung.com>, Alice Ryhl <aliceryhl@...gle.com>
Cc: rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] rust: locks: Add `get_mut` method to `Lock`
On 2/9/24 13:22, Mathys-Gasnier wrote:
> From: Mathys-Gasnier <mathys35.gasnier@...il.com>
>
> Having a mutable reference guarantees that no other threads have
> access to the lock, so we can take advantage of that to grant callers
> access to the protected data without the the cost of acquiring and
> releasing the locks. Since the lifetime of the data is tied to the
> mutable reference, the borrow checker guarantees that the usage is safe.
>
> Signed-off-by: Mathys-Gasnier <mathys35.gasnier@...il.com>
> ---
> [...]
> + /// Gets the data contained in the lock
I wish that this doc comment mentioned what you've said about having a
mutable reference avoids locking, much like the documentation on
`std::sync::Mutex::get_mut`. If you do so then you can add my reviewed.
Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@...il.com>
> + pub fn get_mut(&mut self) -> &mut T {
> + self.data.get_mut()
> + }
> }
> [...]
Powered by blists - more mailing lists