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...

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).

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/crossb...

Note that the mpsc queue in the rust stdlib is also a clone of crossbeam and therefore also lockless.

Oh, interesting. Ok I take back my claim then.

> 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?

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

Thanks.