The BEAM provides the infrastructure, but you need to write the code to glue things together into a consistent distributed system - and to be clear, once you have TWO GenServers you’re trying to make change together you’re in distributed-system territory.

For instance, here’s a very basic “table with a lock” GenServer (see below for notes):

defmodule TableWithLock do
  use GenServer

  defstruct [:data, :owner]

  def unlock(pid), do: GenServer.call(pid, :unlock)
  def lock(pid), do: GenServer.call(pid, :lock)
  def update(pid, fun), do: GenServer.call(pid, {:update, fun})

  @impl true
  def init(data) do
    {:ok, %__MODULE__{data: data, owner: nil}}
  end

  @impl true
  def handle_call(:lock, {pid, _tag}, state) do
    cond do
      is_nil(state.owner) ->
        # unlocked, pid now owns lock
        {:reply, :ok, %{state | owner: pid}}

      state.owner == pid ->
        # already locked by pid
        {:reply, :ok, state}

      true ->
        # locked by another process
        raise "oh no lock contention"
    end
  end

  def handle_call(:unlock, {pid, _tag}, state) do
    cond do
      is_nil(state.owner) ->
        # already not locked
        raise "somebody already unlocked this???"

      state.owner == pid ->
        # locked by the caller
        {:reply, :ok, %{state | owner: nil}}

      true ->
        # locked by somebody else
        raise "unlocking somebody else's lock"
    end
  end

  def handle_call({:update, fun}, {pid, _tag}, state) do
    cond do
      is_nil(state.owner) ->
        # not locked
        raise "not locked"

      state.owner == pid ->
        # locked by the caller
        result = fun.(state.data)
        {:reply, result, %{state | data: result}}

      true ->
        # locked by somebody else
        raise "updater not holding the lock"
    end
  end
end

{:ok, pid1} = GenServer.start_link(TableWithLock, [1,2,3])

:ok = TableWithLock.lock(pid1)

result = TableWithLock.update(pid1, fn data -> Enum.map(data, & &1*2) end)

:ok = TableWithLock.unlock(pid1)

IO.inspect(result)

There are a LOT of places where this could be work better / handle concurrency better:

• crashing the table when a second process tries to take the lock is not realistic. A better implementation would keep a queue of pids that are currently trying to take the lock in lock and pick the next one to reply to in unlock.
• crashing the table on bogus unlocks isn’t realistic either. An alternative would be to return something from handle_call that the implementation of unlock/1 could use to crash the calling process, since unlocking a table that you haven’t locked is a logic error
• if a process dies while holding the lock, it will never be unlocked. Tools like Process.monitor can help with this, at the cost of additional complexity.

Expanding this setup to TWO tables adds some extra complications:

• if process A takes lock 1 and then tries to take lock 2, while at the same time process B takes lock 2 and tries to take lock 1 the system is in a classic DEADLOCK situation. The default 5s timeout on GenServer.call will eventually pick a winner, but real systems will detect this and complain

• coordinating changes to ensure that they either all appear or all do not is still just as tricky as always. You’d need a third process to coordinate the TableWithLocks and roll back changes if a future change fails.

  Note that even the code in your example does not produce atomicity - if mutate2 returns false, the changes from mutate1 are still visible.

  Solving this problem correctly is capital-H Hard and the solutions are highly sensitive to exactly what tradeoffs your particular application can tolerate.