>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) BK> Yes this relies on all actors being the same type , which is pretty hard. 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? BK> The basic idea with disruptor is the thread is working all the time with no context switches / TLB or Cache flushes , no contention and no IO blocking or locking ...if you want IO you send an async message to an IO process then process the next message . If the IO has a result its a new message. Because there is no thread syncronization etc you get a big boost in cache hits so you end up easily processing 100K messages per second , and the LMAX people pushed it to 6M transactions per second on standard PC HW with Java on 1 thread ! . Martin Fowler has a good paper on it. BTW They tried actor first but found this model better . Latency is quite low due to the huge processing capacity. Also note even though there are call backs its all single threaded so easy to code .. I do think you can do better than Disruptor with Actor like services eg you need to have actors of certain types processed by a service with a message pump ( which could be load balanced ) , similar / related work grouped into the same actor and and all inter actor communication point to point - No service bus / router with contention etc. With point to point queues you can do lock-less reading and writing . Obviously managing these queues and wiring them up is not trivial . Lastly you really want actors that are chatty talking via shared memory or grouped in the same domain by the time you go to an IP stack your performance will be attract much higher latency and a throughput penalty . I would be interested to know how akka or erlang solve the above problem of distributing actors to threads. BK> Erlang is good but its more from the point of safety and ease of coding than performance. If you don't need extreme performance you should use it !. _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
