[Groxx]

Since I am not familiar enough with Erlang to know, is that actually the same as concurrent code? I can certainly see how it would share many of the same logical issues, but does sharing an actor imply that you can have non-atomic operations on the actor, like inconsistent writes and reads? I was under the impression that it would at least be atomic because actors are single-threaded. It even guarantees message ordering, while memory does not in some widely used hardware architectures.

You can of course rebuild data races inside Erlang with the right set of messages, but it's not surprising that you can emulate a Turing-complete computer in a Turing-complete language.

[Twey]

The operations are atomic because of the single-threaded nature of actors. But the operations can be arbitrarily ordered, except for the pairwise ordering constraint (which mirrors the happens-before relation on memory within a thread). If your memory actor has operations like ‘read address’ and ‘write address’ then yes, you precisely get the behaviour we enjoy from shared memory: if you read one address A then address B someone might have changed both of them in the meantime, and if you write A then read it back it might have been changed in the meantime.

The difference is that you're not limited to just ‘read address’ and ‘write address’ operations: the shared actor gets to define higher-level operations that are atomic over larger sections of code.

[Groxx]

tbh I think "concurrently shared memory that has no data races" is pretty significantly different from practically every other example of shared memory out there. you'll get Mem's behavior in single threaded async system with immutable data (because another actor can't mutate the data you've already received), but I can't think of anything else. that misses on both concurrency and "shared memory" since it's not actually shared. it's shared-readable or something along those lines.