Minimalist C# Actors

Actor.cs

// Inspired by https://gist.github.com/2557678
// and http://dspace.mit.edu/bitstream/handle/1721.1/6935/AITR-633.pdf
using System;
using System.Collections.Concurrent;
using System.Collections.Generic;
using System.Threading.Tasks.Dataflow;
using Message = System.Object;
namespace Actors
{
    public interface Behavior { Behavior OnArrival(Message message); }
    public class Actor
    {
        private volatile Behavior behavior;
        private readonly ActionBlock<Message> arrivals;

        public Actor(Behavior initialBehavior)
        {
            this.behavior = initialBehavior;
            this.arrivals = new ActionBlock<Message>(message => { this.behavior = this.behavior.OnArrival(message); });
        }

        public void Send(Message message)
        {
            this.arrivals.SendAsync(message);
        }
    }
}

How do other Actors send messages to this Actor? (SEND operation)

How do you do "Stay" / "Die"?

What guarantees memory visibility of lastEvent?

The "SEND" operation is called "activator" in this model. So an actor sends a message by invoking activator(target, message)

"Stay" is simply "return this" in a behavior.
I guess "Die" would be a to return a noop behavior

I'm assuming that "lock" provides the necessary guarantees to ensure that the lock is visible to all concerned threads.

Ah, ok, but since actors do not have identities you cannot obtain a reference to "target".

Cool.

No, it won't since lastEvent is a variable and I assume that there is no mfence issued after constructor invocation completion so initial behavior might be lost.

Removed the activator stuff and made it implicit in a public Send, much clearer.
I'm not sure I'm buying your concern regarding the constructor though. Even without a fence after the constructor it is still the case that any access besides the constructor goes through the lock, which should have a fence.

Regarding actor references, you have the identity of any actor you create, but you are probably correct about the self awareness issue though.

My point is that if there's no mfence after the constructor, and the reference to the newly created Actor instance is done unsafely (i.e. w/o proper fencing) any other entity sending a method to it might see the original value of the lastEvent field, which will be null, and so the lock on null will barf.

hmm, can't seem to find any definitive documentation on this. lock introduces memory barriers but it is not clear if reading the monitor is safe. Official documentation contains example code that should exhibit the same issue though so I guess it should be safe.

Couldn't trigger the issue in a unit test either (4 core Intel I7)
Did determine that the Task-scheduling was roughly 1-2 magnitudes slower than ConcurrentQueue.Enque though...

You'll have to unsafely publish the reference to the newly allocated Actor and have the thread that picks it up send it a message.