Stateless Actors

Discussion (5 Comments)Read Original on HackerNews

mrkeen•about 2 hours ago

A race condition:

  Two processes intend to add two to a number.

  They each read the current value.

  Then they each write back the value which is two bigger then the original.

If you instead use private fields and public getters/setters, or use actors to form a protective bubble around the mutable state, you get...

The exact same thing but with more boilerplate.

hackyhacky•37 minutes ago

The key feature of Erlang-style actors is that messages are enqueued and processed serially, thus eliminating race conditions of this type.

layer8•17 minutes ago

If the read and the write are separate messages, i.e. the computation of the modified value happens sender-side, as in the parent example, then I don’t see how a serializing queue prevents the race condition, for two concurrent senders (clients). For that you need transactions, exactly like a database.

hackyhacky•10 minutes ago

That's not how you would implement mutating messages in an actor system. Instead you could do either of these:

* Have an "increment" message that adds n to the current value and returns the old value.

* Have separate "read" and "write" messages, where the "write" message is parameterized by a timestamp returned by the "read" message. If the owner detects that the timestamp sent by the write is older than the most recent timestamp, it's rejected.

Because messages are handled serially, it's easy and safe to create messages that behave sanely event without explicit locks.

toast0•11 minutes ago

It's easier if you have actors with state (which then doesn't fit the title of the article, which I didn't read), and you send it a message to add two and return the current value.

One sender would get an out of date value, but it was current when sent.

Stateless Actors

⚡ Community Insights

Discussion (5 Comments)Read Original on HackerNews