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 2 hours ago | parent [-]

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 2 hours ago \| parent [-]
		> 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.