Skip to content

Explain why we should avoid static mutable variable and introduce interior mutability #390

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

EvansJahja
Copy link

Closes #389

@@ -23,6 +23,8 @@ fn main() {

But this has a few problems. It is a mutable global variable, and in Rust, these are always unsafe to interact with. These variables are also visible across your whole program, which means the borrow checker is unable to help you track references and ownership of these variables.

Up until Rust 2024, the usage of static **mutable** variable has been discouraged. Since Rust 2024, static mutable variable results in an error. Of course, there are legitimate use case of having a shared mutable state, it's just that Rust want you to really think about the scope of the mutability. We'll talk about this later when we talk about interior mutability.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When read literally, "Since Rust 2024, static mutable variable results in an error." is wrong.

A static mutable variable in itself is not an issue at all, if you are comfortable with unsafe code: https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=a9bb1d76aa1ef7cb07442d890438cd7d

What's discouraged is using references to static mutable variables:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=7b96c2c8023526d86d8f9b619eda9846
And even there, it's not a hard error, but a deny lint, that can be overridden (#[allow(static_mut_refs)])

Perhaps make that "Since Rust 2024, references to static mutable variables are denied by default."?


Of course, none of the above are safe. In order to get a proper interior mutability that is safe, we should implement `Sync` ourself and put in our synchronization primitive specific to the hardware such as locking the resource with atomic swap and guarding the code with interrupt-free section (disable interrupt, run some code, enable interrupt), also known as critical section.

You could check how [rust-console gba](https://github.com/rust-console/gba/blob/6a3fcc1ee6493a499af507f8394ee542500721b7/src/gba_cell.rs#L63) implement it for reference.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this example a bit too specific and complicated?
I don't have a better example at hand though. Not a big deal, if someone has a better suggestion, it can easily be replaced later.

@jannic
Copy link
Member

jannic commented May 24, 2025

I very much like what you wrote, it explains the topic well and is easily understandable!

What I did not yet check is how well this section fits into the book. I only read the diff in isolation, and the last time I read the book was a long time ago, so that should be judged by someone more familiar with the book.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Discourage use of static mut in singleton
2 participants