5

I am trying to wrap my head around how akka.net concurrency handles cache coherence. Let say I have an Actor that stores some state as a instance field, I understand that only one message is handled at a time. But each message might be processed by a different thread from the thread pool, possibly on a different core/socket. How is akka.net ensuring that different thread sees all changes made to the state field?

A somewhat similar discussion regarding akka https://www.lightbend.com/blog/akka-and-the-java-memory-model, but I am not sure the cache coherence question was properly answered (see last comment).

Lars KJ
  • 632
  • 7
  • 15
  • I haven't used the most recent versions of Akka.NET, but in the past the default threadpool was built on top of TPL, so I imagine that if this is still the case then it's a question of how the .NET framework handle's cache-coherence. – easuter Aug 27 '16 at 22:27

1 Answers1

3

In terms of cache coherence - the actor's state is only ever read on a single thread at a time (whichever thread is processing the actor's mailbox) and typically that actor is going to process up to 30 messages at a time before yielding the thread to another actor. It's similar to how quantums work in the normal Windows / Linux scheduler.

Therefore, you can view the updates to an actor's memory as transactional - there's no way for two processors to access an actor's memory at the same time since it's private and accessible by only a single thread at a given time. As a result of this cache coherency isn't an issue to begin with because the actor model forces a linearizable history of reads and writes to the state.

Aaronontheweb
  • 8,224
  • 6
  • 32
  • 61