Difference between revisions of "Actor Model"
From MohidWiki
| Line 17: | Line 17: | ||
<p>[[File:am.04.png|thumb|right|alt=(4) Comment.|Name.]]Lets take a look at the system in a moment all actors are computing the next time-step. Is is non-determined which actor will terminate first (even if we know each one work load, it is impossible to know when they will terminate their computations). Even while computing they are checking their mailboxes because there are messages they can react to (for instance if they are asked if their run has ended or not). Messages they can not process stay in the queue. Messages are not processed in the order of arrival.</p> | <p>[[File:am.04.png|thumb|right|alt=(4) Comment.|Name.]]Lets take a look at the system in a moment all actors are computing the next time-step. Is is non-determined which actor will terminate first (even if we know each one work load, it is impossible to know when they will terminate their computations). Even while computing they are checking their mailboxes because there are messages they can react to (for instance if they are asked if their run has ended or not). Messages they can not process stay in the queue. Messages are not processed in the order of arrival.</p> | ||
| + | |||
| + | |||
| + | Traditional server-side architectures rely on shared mutable state and blocking operations on a single thread. Both contribute to the difficulties encountered when scaling such a system to meet changing demands. Sharing mutable state requires synchronization, which introduces incidental complexity and non-determinism, making the program code hard to understand and maintain. Putting a thread to sleep by blocking uses up a finite resource and incurs a high wake-up cost. | ||
| + | |||
| + | The decoupling of event generation and processing allows the runtime platform to take care of the synchronization details and how events are dispatched across threads, while the programming abstraction is raised to the level of business workflows. You think about how events propagate through your system and how components interact instead of fiddling around with low-level primitives such as threads and locks. | ||
| + | |||
| + | |||
<p>[[File:am.02.png|thumb|left|alt=Actor MW3 is the first actor to terminate its time-step.|(1) Actor MW3 is the first actor to terminate its time-step.]]Suppose Actor MW3 is the first actor to terminate its timestep. It sends messages to other actors with border conditions. MW3 has no messages in its mailbox so it is idle. Actor MW2 has a message in its mailbox but it can not process it yet so the message stays there.</p> | <p>[[File:am.02.png|thumb|left|alt=Actor MW3 is the first actor to terminate its time-step.|(1) Actor MW3 is the first actor to terminate its time-step.]]Suppose Actor MW3 is the first actor to terminate its timestep. It sends messages to other actors with border conditions. MW3 has no messages in its mailbox so it is idle. Actor MW2 has a message in its mailbox but it can not process it yet so the message stays there.</p> | ||
Revision as of 10:42, 23 January 2014
There are several resources in the Internet explaining the Actor Model and Reactive Programing. Some videos with interesting interviews:
- Hewitt, Meijer and Szyperski: The Actor Model (everything you wanted to know, but were afraid to ask)[1]; and
- Francesco Cesarini and Viktor Klang on the Reactive Manifesto[2].
To read on-line:
According to the Wikipedia[5] "the actor model in computer science is a mathematical model of concurrent computation that treats "actors" as the universal primitives of concurrent digital computation: in response to a message that it receives, an actor can make local decisions, create more actors, send more messages, and determine how to respond to the next message received" (changing state).
Actor Model in Mohikd
Suppose a domain is decomposed in 3 sub-domains according to the image at the left. Each sub-dmain is an actor that sends messages to other actors and reactes to messages it receives. Each model has a Main Loop that progresses in time-steps. Each model sends messages with information (for example border conditions) to actors that need it. Lets take a look at the system in a moment all actors are computing the next time-step. Is is non-determined which actor will terminate first (even if we know each one work load, it is impossible to know when they will terminate their computations). Even while computing they are checking their mailboxes because there are messages they can react to (for instance if they are asked if their run has ended or not). Messages they can not process stay in the queue. Messages are not processed in the order of arrival.
Traditional server-side architectures rely on shared mutable state and blocking operations on a single thread. Both contribute to the difficulties encountered when scaling such a system to meet changing demands. Sharing mutable state requires synchronization, which introduces incidental complexity and non-determinism, making the program code hard to understand and maintain. Putting a thread to sleep by blocking uses up a finite resource and incurs a high wake-up cost.
The decoupling of event generation and processing allows the runtime platform to take care of the synchronization details and how events are dispatched across threads, while the programming abstraction is raised to the level of business workflows. You think about how events propagate through your system and how components interact instead of fiddling around with low-level primitives such as threads and locks.
