6 ms·
Hm, this distinction between non-atomic and atomic ref counting sounds like a scat-gun sized footgun waiting to go off when it is least expected. Is there any p
by gmueckl 9y ago
Hm, this distinction between non-atomic and atomic ref counting sounds like a scat-gun sized footgun waiting to go off when it is least expected. Is there any protection for non-atomic ref counting in a multithreaded environment in Rust?
- the_mitsuhiko 9y ago> Is there any protection for non-atomic ref counting in a multithreaded environment in Rust? Yes. It errors at compile time (`std::rc::Rc<i32>` cannot be sent between threads safely)
- pcwalton 9y ago> Is there any protection for non-atomic ref counting in a multithreaded environment in Rust? Of course. Rust is memory safe. The compiler will prevent you from sharing non-thread-safe reference counted objects between threads. This is a significant advantage over C++, where the compiler offers no such protection and so the typical solution is just to use atomic reference counting (shared_ptr) everywhere.
- gmueckl 9y agoSo are you claiming that the exact same solution is good in rust and bad in C++?
- the_mitsuhiko 9y agoI'm not the person you are replying to but I would never use a non atomic refcounted smart pointer in C++ because the risks associated with it are just too high. In Rust however the compiler protects me from misuse. Separately emotionally I feel different about Arc<T> because all the counting is explicit and I see it. Understanding where shared_ptr<T> in C++ counts however can be quite a challenge, even if you consider yourself proficient with C++.
- gmueckl 9y agoI may be in the minority here, but if you are programming properly, your understanding of the code should always be good enough that this is a non-issue. If you manage to trigger a compiler error like this at all, you are most likely hacking, not developing.
- pcwalton 9y agoReference count problems routinely result in vulnerabilities. Google for [cve reference count].
- gmueckl 9y agoBut these vulnerabilities can only happen if reference counting is not automatic, right?
- pcwalton 9y agoNo, because of the way references in C++ work—you can take a reference to the inside of a reference counted object without manipulating the reference count. They could also happen if you used non-thread-safe reference counting on a thread-safe object. Now this seems to be rare in practice, because non-thread-safe reference counting is unusual. If it became more prevalent, however, I could see it happening.
- the_mitsuhiko 9y agoShould probably but I'm not a good enough developer (yet?) to guarantee that. I rather take the extra safety from the compiler.
- empath75 9y agoReal programmers apparently never make mistakes.
- moosingin3space 9y ago
- moosingin3space 9y agoI'm not pcwalton, but he is correct. The Rust compiler only allows objects that implement the Sync trait to cross thread boundaries. Rc<T> is not Sync, while Arc<T> is. Sync is a marker trait, with impls automatically generated by the compiler for types that are comprised entirely of Sync types, or manually (and unsafely) specified by the author. As a result, Rc<T> cannot be misused from multiple threads without unsafe. To learn more about this, look here: https://doc.rust-lang.org/beta/nomicon/send-and-sync.html https://doc.rust-lang.org/beta/nomicon/send-and-sync.html