[mrkeen]

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]

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

[layer8]

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]

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.

[mrkeen]

You wouldn't implement the "plus 2" program in an actor system this way, because of race conditions.

Same as you wouldn't implement the "plus 2" program in an OO, functional, or this way, because of race conditions.

Either way, it's up to programmer discipline.

[hackyhacky]

> You wouldn't implement the "plus 2" program in an actor system this way, because of race conditions.

Can you explain how a serially-executed "increment" message in an actor system, as I've described above, would cause a race condition?

In an OOP system you could do the same, you'd just have to build the thread-safe message queue yourself. In actor languages it's built in.

There are cases where you can get race conditions in actor languages, but I'm pretty sure this isn't one.

[layer8]

The point is that you have to implement it in the specific ways you describe in order to prevent a race condition. The actor model doesn’t eliminate race conditions by itself. This is true in all programming models. A database also doesn’t eliminate race conditions, you have to use appropriate transactions in order to prevent them. What you describe for the actor model is virtually the same thing: you have to use transactional messages in order to prevent race conditions. And that doesn’t happen by itself, the programmer has to implement the program logic in that specific way. There is no magic silver bullet.

[mrkeen]

This is correct, but databases only help to the extent that the whole world is happy to live in your database.

As soon as you have customers (who interact via REST), or partner payment systems (e.g. stripe) you're back to:

  Two customers do a GET.  This gets dispatched to the DB, wrapped in a nice transaction, the transaction ends, the customers get their result.

  The two customers then do a POST to set a new value.  Also wrapped in a transaction.

Race condition with more steps.

[hackyhacky]

As I pointed out above, that's not the API that would be exposed in an actor model. See in particular the timestamp-based update condition, if you're principally concerned with end-user-caused races.

Less relevant, but message queues in Erlang and related languages are typically in-memory, no DB transaction required.