How the "actor model" resolve the "shared state" problem? - erlang

Question

It seems the "withdraw" porg is the classic example,it's used in 《sicp》 and 《design concepts in programming languages》to explain the "shared state"
I want to know in the "actor model" is there some method to aovid the "shared state"? But I can't find a good example write in erlang/elixir to show it
There is an example of withdraw in 《programming erlang》2ed,chapter 22,but the example seems to show how to write the opt,not how to deal the "shared state":it use ets database to save the "balance",so the ets is the "shared state",and it use only one process,not two to "withdraw" and "deposit"
So is there some good example of "withdraw" to show how erlang/elixir deal with the "shared state" problem?I think it have to encode the balance in the message to handle it,and pass the "balance" everywhere,to aovid share it in a fix place.Maybe haskell's MVar will resolve it

Answer 1

An actor, or an Erlang/Elixir process, is in effect a single thread. If you're in a GenServer's handle_call function you are guaranteed to not receive another message or invoke another handle_call until this particular message handler is complete. All messages sent to a process are received in some order and handled one at a time; there is no concurrency within a process and so no opportunity for state to be concurrently modified.
A minimal Elixir setup might look like
defmodule Account do
use Genserver
def start_link(balance) do
GenServer.init(__MODULE__, balance)
end
def deposit(account, amount) do
GenServer.call(account, {:deposit, amount})
end
def withdraw(account, amount) do
GenServer.call(account, {:withdraw, amount})
end
#impl true
def init(balance) do
{:ok, balance}
end
#impl true
def handle_call({:deposit, amount}, _, balance) do
new_balance = balance + amount
{:reply, :ok, new_balance}
end
#impl true
def handle_call({:withdraw, amount}, _, balance) do
if amount < balance do
{:reply, {:error, :insufficient_balance}, balance}
else
new_balance = amount - balance
{:reply, :ok, new_balance}
end
end
end
In a classical multi-threaded environment with mutable state, you have an opportunity for one thread to calculate a new_balance while another thread overwrites the existing balance, and changes can get lost. (You cite Structure and Interpretation of Computer Programs and it has an entire subsection describing the issues here.) But since the actor is single-threaded, even if multiple other processes call Account.withdraw/2 on the same account, you're guaranteed to get a consistent behavior.

Answer 2

Just to add to what David Maze explained: a process sends a message to an OTP genserver by calling the function:
gen_server:call(GenserverModuleName, Message)
When processA calls that function, a message is sent to the genserver process, for example in Chapter 22 the message might be a withdrawal: {remove, "account0001", 200}. When processB calls that function, another message is sent to the genserver process, e.g. another withdrawal: {remove, "account001", 1000}. The genserver process, like all erlang processes, has a mailbox that accumulates messages from all the processes that send it messages.
The genserver then searches through the mailbox for messages that it knows how to handle, e.g. messages that match the parameters specified in the various clauses of the handle_call() function definition. However, a genserver only works on one message at a time, therefore there can be no race condition, i.e. where two processes try to change the same piece of data at the same time, like the account balance. The genserver will handle one withdrawal message, and if the account has a big enough balance, then the withdrawal is allowed, and the balance is updated in the ets table. Then the genserver will handle the next withdrawal message, and if the new balance is sufficiently large, the second withdrawal is allowed, and the balance is updated in the ets table. In other words, the genserver does not spin off two processes to handle the two withdrawal messages concurrently, rather the genserver handles the two withdrawal messages sequentially.
it use ets database to save the "balance",so the ets is the "shared
state
The genserver is the only process that knows about the ets table, and the genserver only accesses the ets table sequentially.
I think it have to encode the balance in the message to handle it,and
pass the "balance" everywhere,to aovid share it in a fix place.
No, the balance can remain in the ets table for the reasons stated above.