[erlang-questions] STM vs Actor Model?

[ok@REDACTED]

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

Observation 1: if the room manager is to know which is "the room
with the least people", it *has* to be a serialisation point.

Observation 2: you probably *don't* need to know what is the absolute
best room.  You just need not to pick bad rooms.  So you could have
M managers each managing N rooms.  When a person arrives, it picks a
random manager and asks it what room to go to.  If a manager has no
suitable rooms, it sends a "try another manager" response.  This
reduces the amount of traffic each manager has to handle by a factor
of M.  This is very likely *better* than TM would gives you.

A slightly different design would have a meta-manager.  Just as
rooms tells their manager when their occupancy changes, so managers
tell the meta-manager when their "close to overload" status changes.
A manager with too little spare capacity delegates requests to the
meta-manager, which forwards them to managers that aren't overloaded.

This is just a rough sketch, but the key principle is "don't try
to speed up contention points, *eliminate* them."
>
> 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?

Message passing in Erlang is asynchronous.  If process S sends
a message to process R, S does not wait.  If S wants a reply
from R, it may have to wait for that, not because of anything
about Erlang's implementation, but just because of the logic of
the situation.

Some Erlang processes exist in order to be serialisation points.

Let me put it this way.  I do want my phone to be able to receive
and store text messages while I'm making a call.  But I don't
want it accepting a second call while I've already got one in
progress.  If two things can happen at the same time, they should
be handled by two processes.

It is certainly imaginable that ETS and DETS might benefit from
some sort of lock-free or TM implementation underneath.  And it
is equally imaginable that there may be NIFs that should be
doing something like that.  There is an article on ETS and TM
that you may find interesting: http://dl.acm.org/citation.cfm?id=2034658