The only replacement for locks/mutexes is a lock free data structure. Locks are not what make concurrency possible, they are what makes it data-safe.

You can use platform threads, user-space threads, language-provided "green" threads, goroutines, continuations or whatever you wish for concurrency management, but that's almost orthogonal to data safety.

I'm not sure what you mean here, as far as I'm aware data safety isn't standard terminology.

I think they’re using it in the context of what you’ll get without some degree of locking, which is data corruption and/or other issues.

It’s not that you need locking to use threads. You need locking to stop threads from ruining any shared resource/data they are both trying to touch at the same time.

The x86 instruction set is available as well.

Actors are implemented using locks.

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.