[erlang-questions] STM vs Actor Model?

[Bin Wang]

Hi, Richard

Thanks for the answer. One of the situation is like this:

I have a chat service that would have many rooms. Each room have a
limit of the max number of people. When a people comes, it will enter
the room with the least people. I treat every person as an actor and
the room manager as an actor. So every time the people enter or leave,
it will ask and send request to the room manager to update its state.

So the room manager seems to be a single point which may receive many
requests. I'd like to see if STM could speed it up.

And more, if it could speed things up in general.

In distributed system, actors could send messages to each other. But
while on the single machine, is it possible to don't just block the
whole actor while we are requesting it for something?

2014-05-06 13:39 GMT+08:00 Richard A. O'Keefe <ok@REDACTED>:
>
> 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".
>
>