i am working on a code with both multi threaded and single-threaded parts. in the single-threaded part, i have a group of integral components of type Rc<RefCell<_>> (around 5 of those components currently, but i would probably need more). those components work fine, but since parts of the code are multi threaded, sometimes i do run into thread issues (not many though). since those issues are very annoying, i was wondering if i should use an Arc. i heard Arc takes a lot of memory, but at the same time, those errors are really, really annoying. so, I'm wondering how large is the difference between Rc and Arc during runtime, and what would you guys recomend for me to do.
The only difference between Rc and Arc is that Arc uses atomic operations when it updates the reference counts, and Rc does not. They occupy the same amount of memory.
4 Likes
If you are using concurrency at all with Rc<T>, you should switch it to an Arc<T>. Arc does not take more memory, it just takes a slightly longer amount of time to clone and drop the shared object. (Here is the atomic module, which gives a longer description of what they are.)
You should never share an Rc<T> across threads, because it can result in the memory not being freed, freed memory being accessed, or other undefined behavior. As always, I recommend benchmarking your code so you can use Arc<T> with the confidence that it is worth the slight performance hit.
5 Likes
omfg how did i forgot that i can just benchmark them, thanks for the answer
Rc is !Send/!Sync so compiler won't let you share it.
1 Like
When people write such strong assertions, I always wonder where they got this misinformation from. Why would Arc use "a lot of" memory in itself? I mean, the tools in std are obviously well-optimized, and they are there to be used. They weren't created by some evil magician to eat up all your available RAM.
Aside from that, did I understand correctly that you are somehow forcing explicitly not thread-safe abstractions such as Rc and RefCell into a threaded context? Are you maybe using unsafe for that? If so, you need to stop doing that immediately. Data races in Rust are not merely "annoying", they are undefined behavior.
6 Likes
i thought it took a lot of memory since every time i was using Arc in my code, phind.com would say that it takes a lot of memory, and people would recommend removing the Arc for an Rc. also, most multi threaded programs in rust take a lot of ram, so i thought Arc had something to do with it.
also, the reason i called those errors annoying are becasue i tried to avoid using unsafe as much as possible, which made moving Rc accross threads very annoying, i'm not that stupid to just write unsafe on every error i get lol
As mentioned above, that wouldn't make a difference. Whoever gave you that piece of advice probably did not understand it themselves.
No. Compute-heavy parallel programs take a lot of memory because they want to read the whole input into memory (in the most naïve case anyway) so that they can process it at once more easily.
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.