3 ms·

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

by FpUser 6mo ago

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.

LtdJorge 6mo ago
Use a LazyLock for your state, then
kd5bjo 6mo ago
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.
- Ciantic 6mo ago
  I happen to be just now experimenting with app states. Out of interest, you mean something like this? https://gist.github.com/Ciantic/63526ebfe65570b669eca33bf3404b69 https://gist.github.com/Ciantic/63526ebfe65570b669eca33bf340... 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.
  - maxbond 6mo ago
    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.
deleted 6mo ago
[deleted]
mplanchard 6mo ago
You can Box::leak() it to make a &’static ref to it.
VonTum 6mo ago
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

by FpUser 6mo ago

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.

LtdJorge 6mo ago

Use a LazyLock for your state, then

kd5bjo 6mo ago

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.

Ciantic 6mo ago
I happen to be just now experimenting with app states. Out of interest, you mean something like this? https://gist.github.com/Ciantic/63526ebfe65570b669eca33bf3404b69 https://gist.github.com/Ciantic/63526ebfe65570b669eca33bf340... 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.
- maxbond 6mo ago
  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.

deleted 6mo ago

[deleted]

mplanchard 6mo ago

You can Box::leak() it to make a &’static ref to it.

VonTum 6mo ago

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