Actor Model: Difference between revisions
No edit summary |
|||
| (8 intermediate revisions by the same user not shown) | |||
| Line 10: | Line 10: | ||
* [[Software Architecture#Subjects|Software Architecture]] | * [[Software Architecture#Subjects|Software Architecture]] | ||
* [[Object-Oriented Programming]] | |||
=Overview= | =Overview= | ||
The actor model is a mathematical model for concurrent computation. The model's primitive is the [[#Actor|actor]], which is an entity that sends and receives [[#Message|messages]]. | The actor model is a mathematical model for concurrent computation. The model's primitive is the [[#Actor|actor]], which is an entity that sends and receives [[#Message|messages]]. The essence of the model is that individual actors maintain state independently of each other and passing messages to each other. In response to a message, an actor can make local decisions, create more actors, send more messages and determine how to respond to the next message received. Actors may modify their own private state, but they can affect each others through messages, avoiding the needs for any [[Concurrent_(Parallel)_Programming#Overview#Concurrency_and_Locking|locks]]. Metaphor: actors are their own islands and can only communicate via message-in-a-bottle across the ocean that separates them. | ||
=Concepts= | =Concepts= | ||
| Line 27: | Line 28: | ||
An actor has an address, so other actor can send messages to it. | An actor has an address, so other actor can send messages to it. | ||
From a programming model perspective, an actor can be thought as an object with access to its own private state no-one else has access to, and its own thread. In an [[Object-Oriented Programming#Overview|object-oriented programming model]], threads share state. Actors share nothing. | |||
==Message== | ==Message== | ||
==Actors and Concurrency== | |||
Actors have no shared state, so there cannot be race conditions. <font color=darkgray>What about the order in which messages arrive? Is that relevant to the model?</font> | |||
Because the actors share nothing, they don't have to live on the same machine. That redefines what concurrency is. Traditionally concurrency is thought of as using multiple cores on one machine at the same time. In a world of actors, the concept of concurrency not only includes scaling across CPU cores, but scaling across a computer network. | |||
Latest revision as of 17:42, 31 August 2023
External
- https://en.wikipedia.org/wiki/Actor_model
- https://en.wikipedia.org/wiki/Actor_model_theory
- https://en.wikipedia.org/wiki/Message_passing
- http://www.brianstorti.com/the-actor-model/
- https://anthonylebrun.silvrback.com/actors-vs-objects
Internal
Overview
The actor model is a mathematical model for concurrent computation. The model's primitive is the actor, which is an entity that sends and receives messages. The essence of the model is that individual actors maintain state independently of each other and passing messages to each other. In response to a message, an actor can make local decisions, create more actors, send more messages and determine how to respond to the next message received. Actors may modify their own private state, but they can affect each others through messages, avoiding the needs for any locks. Metaphor: actors are their own islands and can only communicate via message-in-a-bottle across the ocean that separates them.
Concepts
Actor
An actor is a computation unit that maps each received message to:
- a finite set of messages sent to other actors.
- a new behavior - which will govern the response to the next messages.
- a finite set of new actors created.
The actor embodies all three essential elements of computation: processing, storage and communication.
An actor has an address, so other actor can send messages to it.
From a programming model perspective, an actor can be thought as an object with access to its own private state no-one else has access to, and its own thread. In an object-oriented programming model, threads share state. Actors share nothing.
Message
Actors and Concurrency
Actors have no shared state, so there cannot be race conditions. What about the order in which messages arrive? Is that relevant to the model?
Because the actors share nothing, they don't have to live on the same machine. That redefines what concurrency is. Traditionally concurrency is thought of as using multiple cores on one machine at the same time. In a world of actors, the concept of concurrency not only includes scaling across CPU cores, but scaling across a computer network.