Every actor in Swift conforms to the Actor protocol, which has one requirement: an instance property named `unownedExecutor`. Swift uses this property implicitly when, for example, the program calls a method on the actor from outside the actor.
https://developer.apple.com/documentation/swift/actor/unowne...
(One could also argue that, because every actor type is a reference type, every actor also has its identity as part of its state.)
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.
The exact same thing but with more boilerplate.
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.
* 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.
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.
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.