3 comments

  • the__alchemist41 minutes ago
    I think which tools you use for concurrency depends on your code style and what you&#x27;re doing. For example, I haven&#x27;t reached for Arc in a while. Example of the two primary ways I&#x27;ve been doing it:<p>Embedded: Mutex + critical sections + hardware interrupts. The Mutex isn&#x27;t std::Mutex, but a hardware-specific one. (E.g. ARM) works in a similar way. The default syntax is a mess of RefCell, Cell, Option, with the requisite &lt; and &gt; characters. (The Option is so you can insert a value in on init, then it&#x27;s never None) etc. I work around this with macros.<p>PC applications (GUI, 3D etc): std::thread and MPSC receivers&#x2F;transmitters which update a state struct when they&#x27;re ready. Then poll in the GUI&#x27;s event loop or w&#x2F;e. I believe this workflow has worked for me in lieu of Arc because I have been structuring programs with a single main thread, then sub threads which perform non-blocking tasks, then return data to the main thread.<p>Also: If it&#x27;s a primitive type, Atomics are nice.
  • FpUser3 hours 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.
    • kd5bjo3 hours ago
      That&#x27;s also an option available to you: Mutex::new() is const, so there&#x27;s no trouble putting one in a static variable. If the inner value can&#x27;t be const-constructed, you&#x27;ll need a way to prevent access before it&#x27;s initialized; for that, you can use a OnceLock or just Box::leak() the Mutex once it&#x27;s constructed and pass around a simple reference.
    • mplanchard1 hour ago
      You can Box::leak() it to make a &amp;’static ref to it.
    • LtdJorge3 hours ago
      Use a LazyLock for your state, then