[erlang-questions] STM vs Actor Model?

[Richard A. O'Keefe]

On 6/05/2014, at 4:18 PM, Bin Wang wrote:
> I'm coming up with this idea with STM. Please see how about this
> comparing to Erlang's way?
> 
> In Erlang, actors communicate through messages. That is, a request is
> sent, and the actor do one of them at a time.

Right.  However, while the messages in an actor's mailbox are
serialised, this places no constraints on what *other* actors
are doing.
> 
> But in STM way, all requests could be done at the same time.

Well, sort of.

> And then
> see if there are some conflicts.

This means that a transaction must have clear boundaries.

> If so, undo and redo. It seems with
> high performance and less annoying than locks.

Well, maybe.  The thing is that there is no prior bound on
the number of times an (arbitrarily complicated!) transaction
might have to be undone and redone.  In a situation where
locks would have had high contention, transactions will have
high redoes.

Modern STM systems are either done entirely in software,
or in a rather delicate mix of hardware and software.

STM works quite nicely in Haskell because the vast majority
of memory references in Haskell are to logically immutable
data; thanks to the types, the Haskell compiler can detect
the tiny minority of stores that might need logging and undoing.

Erlang, in contrast, does not need special hardware and does
not need heavy duty compilation techniques to reduce STM
overheads.  Indeed, since the mailbox of an Erlang process
is a queue, it *should* be possible to have an Erlang
implementation where process to process communication does not
involve locks.  (After all, an entire operating system kernel
has been built using lock-free data structures, so why not Erlang?)

The thing is that transactional memory is a way of writing
multithreaded imperative programs to run in a single
address space.  But what if you are writing a distributed
program?
> 
> So thinking about this kind of actor or object: it doesn't do only one
> request in the same time. But it will treat its methods as
> transactions. So multi processes to call its methods could be executed
> in the same time and the actor/object will not be blocked in the most
> of the time.

I think the answer here is "show us a problem where you need that".