Re: [PATCH v3 4/5] rust: id_pool: do not immediately acquire new ids

["Danilo Krummrich" <dakr@kernel.org>]

On Tue Oct 28, 2025 at 7:42 PM CET, Yury Norov wrote:
> I'm not sure about this change, but it looks like a lock wrapping
> acquire_next_id().

It leverages the borrow concept of Rust [1].

The Rust compiler ensures that a mutable reference is exclusive, so there can't
be two independent mutable borrows at a time.

This means that if an object A has a mutable reference of another object B, the
compiler prevents a third object C to have a (mutable) reference of B as well.

So what this ensures is that object A has exclusive access to object B within
the same task -- no concurrency involved.

The way this is connected with concurrency and locks is that if an object is
shared between tasks, you would need a lock to obtain a mutable reference, i.e.
the lock provides the precondition for exclusive access.

So, (mutable) references are about ownership, not synchronization.

I sketched up a simplified and runnable example of the idea behind Alice' code
in [2] to play with, in case you are interested -- I think that clarifies it
best. :)

[1] https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=5e67f1ea36b7e4561bcf5b41137284ec
[2] https://doc.rust-lang.org/book/ch04-02-references-and-borrowing.html