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);
        }
    }
}

locking :-(

How do you encode "recur"?

Isn't this line "public Actor(Behavior initialBehavior) { this.lastEvent = Task.Run(() => initialBehavior); }" exposing the "this" reference to another thread inside the constructor?

How do you send messages to it?

The lock models the arrival ordering, same role as a message queue would have.
"recur" ?
Regarding exposing this, I don't think so, there are no explicit references to being passed to the lambda, only the parameter sent to the constructor.

Regarding sending messages. It's kind of a bootstrap problem ;-) the model is kind of a closed system right now..., but a system could be seeded with actors representing stdin and stdout.

Wait, what, you're blocking all senders? wow... ;-)

So your Actor doesn't know itself, which means your model does not support open recursion?
Also, without knowing your own identity, you cannot pass it to other actors you create, and they cannot respond then, which makes them pretty, erm, underpowered?

Uhm only the ones sending to this actor are blocked, and only during the event ordering, the actual activations from one event is executed in parallel (the Task.Run bit at the end)

Hmm, must have missed self awareness as an intrinsic part of the model, will look in to it, but yeah it seems kind of essential...

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.