I must've been a lucky one. I develop software since 80s. Went from directly entering machine codes and up to enterprise middleware, backends and various device control and multimedia game like systems. In all my life I've only had a single case of deadlock. But it cost me more than 24 hours no sleep marathon trying to nail it down. It was related to communication between my custom Directshow filters and threads in a main software.
On one particular project I started by "spamming" relevant interest based forums. Luckily I was a member of said forums for quite a while before I have released my first version. It was about 13 years ago. Strategy had worked and then I got CEO as a partner along with some investment so I no longer had to do it
TLDR but just the heading is already ugly. No single person no matter how nice they're should be able to control our future. Power corrupts, what fucking trust. We are supposed to be democratic society (well looking at what is going on around this is becoming laughable)
I do not have anything resembling problems described. Before I ask AI to create new code (except super trivial things). I first split application into smaller functional modules. I then design structure of the code down to main classes and methods and their interaction. Also try to keep scope small. Then AI just fills out the actual code. I have no problems reviewing it. Sometimes I discover some issues - like using arrays instead of maps leading to performance issues but it is easily spotted.
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.
That's also an option available to you: Mutex::new() is const, so there's no trouble putting one in a static variable. If the inner value can't be const-constructed, you'll need a way to prevent access before it's initialized; for that, you can use a OnceLock or just Box::leak() the Mutex once it's constructed and pass around a simple reference.
What would be disadvanatages of this approach? I don't like Arc's myself either, I would like to see what is best alternative for those in multi threaded apps.
Different commenter but yes, that's exactly what they mean.
The main disadvantage is strong coupling. The shared state inside the static makes it more difficult to test your code. There are ways to reduce this coupling, the most obvious being that you push as much logic as possible into functions that accept a reference rather than use your static directly. Then you minimize the size of the code which is difficult to test, and cover it with end to end testing.
The OnceLock does impose 1 atomic operation of overhead, whereas an Arc imposes 2 (in this case, it can be more if weak references are used). However neither are likely to be important when you consider the overhead of the Mutex; the Mutex is likely to involve system calls and so will dominate the overhead. (If there's little to no contention then the Mutex is a lot like an Arc.)
Your alternative would be to use `Box::leak()` as the parent comment describes, which would force you to pass a reference around (resulting in better coupling) and eliminate overhead from OnceLock. However, it's unlikely to result in any material performance benefit, and you could reduce coupling without departing from your current approach, so I don't think either approach is clearly or overwhelmingly better.
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
reply