This is not a question about shared state as it relates to concurrency. It’s a much simpler question than that.
Rust seems to discourage keeping any data content "global", so that multiple methods can refer to it and even change it. But let's say I’m programming code to play a board game. What if I’m getting very tired of passing the current board -- with piece positions -- around from method to method.
What would be a good design choice to enable a board to be kept off to the side somewhere, where other code could just drop by and make a move (i.e., change the state), instead of passing the same data content from place to place?
This may sound highly specific, but assuming there's a solution, it's a general design concept that could be useful in many situations. Thanks for any suggestions.
You could store the data in several structs by using reference counted pointers and allow mutable access in a synchronized way, RefCell if it is single threaded or RWLock for a multithreaded program.
The key problem is to make the following design goal concurrency-safe, including thread-safe:
Because the Rust language is designed to let the rustc compiler aggressively optimize code, all non-local interactions need either to be proven correct at compile-time, or employ run-time locking and guard primitives (including atomic) to ensure run-time memory and thread safety.