3 ms·

Is it really so? I haven't checked all the implementations, but my take here would be to use a channel with atomics instead of a lock...

• saagarjha 1y ago
  It's probably possible to do if you think about it carefully but generally enqueuing a message is going to take a lock, especially if you can send an arbitrary number of messages (which may require the queue to be reallocated).
  • pimeys 1y ago
    One very common queue implementation you can use to implement actors is the crossbeam-deque. It's work-stealing in nature, works in multi-threaded environments and has no locks. The implementation is quite simple to follow: https://github.com/crossbeam-rs/crossbeam/blob/master/crossbeam-deque/src/deque.rs https://github.com/crossbeam-rs/crossbeam/blob/master/crossb...
    • surajrmal 1y ago
      Note that the mpsc queue in the rust stdlib is also a clone of crossbeam and therefore also lockless.
    • saagarjha 1y ago
      Oh, interesting. Ok I take back my claim then.
    • yubblegum 1y ago
      > One very common queue implementation you can use to implement actors is the crossbeam-deque I can't find any references to a "crossbeam dequeue" outside of Rust sources. Is this a neologism for a "very common" pattern, or just very common in Rust?
      • steveklabnik 1y ago
        crossbeam is a package name. It would be like googling “Nokogiri XML” and only getting Ruby results. The generic name is just Deque. https://en.wikipedia.org/wiki/Double-ended_queue https://en.wikipedia.org/wiki/Double-ended_queue
        • yubblegum 1y ago
          Thanks.