Proper Community Engagement

Posted Sep 8, 2024 9:13 UTC (Sun) by Wol (subscriber, #4433)
In reply to: Proper Community Engagement by NYKevin
Parent article: Rust-for-Linux developer Wedson Almeida Filho drops out

> You cannot ever have multiple mutable references to the same array element (or any other object, for that matter), because the borrow checker forbids it (and if you cheat and do it anyway with unsafe code, it is immediate UB because of noalias). Without mutable aliasing, it's not possible for two different parts of the program to both think they own the Nth slot in the array at the same time.

The only reason I can think of that is a simple locking algorithm - write your pid into a variable, wait a timeout, if your pid is still there you have a lock. That obviously requires everyone to have mutable access to that variable.

Am I right in thinking that would be okay in unsafe code, provided the mutable reference never escaped the unsafe block? I can think of a couple of race conditions, so the unsafe block could lie to the compiler by accident, but the approach is sound if the implementation is correct?

Cheers,
Wol

Proper Community Engagement

Posted Sep 8, 2024 9:22 UTC (Sun) by mb (subscriber, #50428) [Link]

>Am I right in thinking that would be okay in unsafe code, provided the mutable reference never escaped the unsafe block?

The unsafe block as such doesn't give you rights to violate rules.
It gives you access to deref of raw pointers, but you still have to adhere to the rules.
It does also give you access to some unsafe intrinsics, which might be what you need.
But you can't simply put an unsafe block around your data race and then hope it's fine. It's still a forbidden data race.
So you can for example use an unsafe atomic intrinsic to avoid the data race.

Proper Community Engagement

Posted Sep 8, 2024 10:16 UTC (Sun) by LtWorf (subscriber, #124958) [Link]

That algorithm doesn't work.