[zeromq-dev] Actor Model

[Apostolis Xekoukoulotakis]

This question is of interest to me as well.

Let me give some answers, I havent really implemented them yet:

1. Each thread has one socket. You hash the unique name of the actor and
assign it accordingly to a thread.
advantages: no contention.
disadvantages: it cannot work if actors have different processing needs.

You rely on the randomization of the hash function to balance the work.

this is pretty useful for a graph processing system(millions++ of actors)

2.You have a central broker which implements a locking mechanism. Threads
ask for work, they receive the actors name plus the message that needs to
be processed.
All the actors data are shared by all the threads.

advantage:load balancing works all the time
disadvantage: latency because each thread has to request for work.


>From an algorithmic point of view, how is a disruptor pattern faster than a
queue when we want to implement an actor model?

I would be interested to know how akka or erlang solve the above problem of
distributing actors to threads.


2012/12/15 Min Yu <miniway at gmail.com>

> Akka on zeromq would be an another fun for you.
>
> http://doc.akka.io/docs/akka/snapshot/scala/zeromq.html
>
>
> Thanks
> Min
>
> Dec 15, 2012 9:01 PM Gleb Peregud <gleber.p at gmail.com> 작성:
>
> If you want the most natural way to code your program according to
> actor model, just use Erlang. It has a zeromq library, hence you can
> communicate with outside world using zmq.
>
> On Sat, Dec 15, 2012 at 12:27 PM,  <wilfried at hafner.ws> wrote:
>
>
> hi peeps,
>
>
> i would like to ask you for some ideas/hints on an actor-model
>
> design on top of zeromq. zeromq ships with everything i need,
>
> a mailbox, message routing, i don't have to worry about threads etc.
>
>
> i think the straightforward way would be to give every actor
>
> one or more sockets for sending and receiving messages, depending
>
> on the used patterns (pub-sub, req-rep). but it seems to be a big
>
> overhead, since the max. number of sockets per context is limited.
>
> on the other hand, i would have to share some sockets and write
>
> a lot of messaging features by myself. so zeromq would be useful
>
> just for the communication between some processes or nodes.
>
>
> it's similar to an component based entity system, communication between
>
> entities<->entities, entities<->system and system<->system
>
> should be handled through an event/message bus. Although it's not for game
>
> development, 10k+ entities are possible, which would require
>
> at least more than 10k sockets.
>
>
> thank you for your suggestions!
>
>
> best regards,
>
>
> wil
>
>
> _______________________________________________
>
> zeromq-dev mailing list
>
> zeromq-dev at lists.zeromq.org
>
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>


-- 


Sincerely yours,

     Apostolis Xekoukoulotakis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20121215/faa1ec4a/attachment.htm>