6 ms·

Are Rust ref-counts atomic? (I'd assume so). Atomic ref-counts can actually have a surprising amount of overhead in many multithreaded scenarios, so much so th

• the_mitsuhiko 9y ago
  Arc<T> is atomic, Rc<T> is not.
• therein 9y ago
  There is Rc and Arc, the latter being atomic. If you want to pass them between threads, you'll want an Arc, and in fact you will want an Arc<Mutex<Data>> so your data becomes: let data = Arc::new(Mutex::new(Data::new())); And if you want a mutable static global that's accessed across threads, you'll need something like: lazy_static! { // 0 -> None // 1 -> Circles // 2 -> Bezier static ref DRAW_ON_TOUCH: Arc<Mutex<u32>> = Arc::new(Mutex::new(0)); } I love Rust but it is making easy things harder than they need to be.
  • 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 ago
        So are you claiming that the exact same solution is good in rust and bad in C++?
        • the_mitsuhiko 9y ago
          I'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 ago
            I 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 ago
              Reference count problems routinely result in vulnerabilities. Google for [cve reference count].
              • gmueckl 9y ago
  • dbaupp 9y ago
    How is safely accessing a mutable global from multiple threads an easy thing? Also, the Arc isn't needed in lazy_static: just a mutex is enough for mutability, the sharing (which is what Arc controls) comes from being a static.
    • comex 9y ago
      And if there's just a single u32 inside, there's no need for a whole mutex, you can just use a zero-overhead AtomicU32. …or you could, if it were stable.
      • retrocat 9y ago
        AtomicUsize is stable!
• quickben 9y ago
  Imagine your example in a singleton pattern scenario. It would be quite a performance hit.
• pcwalton 9y ago
  > Are Rust ref-counts atomic? (I'd assume so). No, not unless the object is actually shared among multiple threads.