I have shared mutable state which is available through the whole application lifetime. Having ARC in this situation makes no sense, single mutex should be all I need.
If you want to spawn multiple threads, all with access to a mutex, but without putting it behind an Arc, then you can simply spawn all your threads in a std::thread::scope(||{...}). These let you pass references &'scope Mutex<...>
I find Rc or Arc almost never the right tool for a job where I want to "share state" or such
I think which tools you use for concurrency depends on your code style and what you're doing. For example, I haven't reached for Arc in a while. Example of the two primary ways I've been doing it:
Embedded: Mutex + critical sections + hardware interrupts. The Mutex isn't std::Mutex, but a hardware-specific one. (E.g. ARM) works in a similar way. The default syntax is a mess of RefCell, Cell, Option, with the requisite < and > characters. (The Option is so you can insert a value in on init, then it's never None) etc. I work around this with macros.
PC applications (GUI, 3D etc): std::thread and MPSC receivers/transmitters which update a state struct when they're ready. Then poll in the GUI's event loop or w/e. I believe this workflow has worked for me in lieu of Arc because I have been structuring programs with a single main thread, then sub threads which perform non-blocking tasks, then return data to the main thread.
4 comments
[ 2.7 ms ] story [ 19.6 ms ] threadEmbedded: Mutex + critical sections + hardware interrupts. The Mutex isn't std::Mutex, but a hardware-specific one. (E.g. ARM) works in a similar way. The default syntax is a mess of RefCell, Cell, Option, with the requisite < and > characters. (The Option is so you can insert a value in on init, then it's never None) etc. I work around this with macros.
PC applications (GUI, 3D etc): std::thread and MPSC receivers/transmitters which update a state struct when they're ready. Then poll in the GUI's event loop or w/e. I believe this workflow has worked for me in lieu of Arc because I have been structuring programs with a single main thread, then sub threads which perform non-blocking tasks, then return data to the main thread.
Also: If it's a primitive type, Atomics are nice.