PostSharpin’ Part 2 – Actor

In Part 1 I looked at PostSharp’s support for INotifyPropertyChanged, and several handy aspects to help with threading: Background, Dispatch, ThreadUnsafe and ReaderWriterSynchronized. In part 2 I’d planned to look at PostSharp’s Actor support and new features for undo/redo, but life got in the way, so part 2 will cover only the Actor aspect, and part 3 will cover new features in PostSharp 3.2.

Actor

The Actor model hasn’t yet received a lot of attention in the .NET world. The model was first defined in 1973 as a means to model parallel and distributed systems, “a framework for reasoning about concurrency.” The model assumes that “concurrency is hard” and provides an alternative to do-it-yourself threading and locking. It’s built into languages like Erlang and Scala, and there are a number of libraries and frameworks. It’s gotten a recent boost in the .NET world with F# agents, the TPL Dataflow library and Project Orleans.

Conceptually, an actor is a concurrency primitive which can both send and receive messages and create other actors, all completely asynchronous, and thread-safe by design. An actor may or may not hold state, but it is never shared.

Where does PostSharp fit in? Remembering the PostSharp promise: “Eradicate boilerplate. Raise abstraction. Enforce good design.” the PostSharp Actor implementation allows developers to work at the “right” level of abstraction, and provides both build time and run time validation to avoid shared mutable state and ensure that private state is accessed by only a single thread at a time.

To use the Actor aspect, install the Threading Pattern Library package from NuGet.

Ping Pong

I started with the PingPong sample (well, PingPing really) from PostSharp. Here’s the code:

[Actor]
public class Player 
{
    private string name;
    private int counter;

    public Player(string name)
    {
        this.name = name;
    }

    public async Task Ping(Player peer, int countdown)
    {
        Console.WriteLine("{0}.Ping({1}) from thread {2}", this.name, countdown,
                          Thread.CurrentThread.ManagedThreadId);

        if (countdown > 1)
        {
            await peer.Ping(this, countdown - 1);
        }

        this.counter++;
    }

    public async Task GetCounter()
    {
        return this.counter;
    }
}

class Program
{
    static void Main(string[] args)
    {
        AsyncMain().Wait();
        Console.ReadLine();
    }

    private static async Task AsyncMain()
    {
        Console.WriteLine("main thread is {0}", Thread.CurrentThread.ManagedThr

        Player ping = new Player("Sarkozy");
        Player pong = new Player("Hollande");

        Task pingTask = ping.Ping(pong, 10);

        await pingTask;

        Console.WriteLine("{0} Counter={1}", ping, await ping.GetCounter());
        Console.WriteLine("{0} Counter={1}", pong, await pong.GetCounter());
    }
}

Here the Player class is an actor, and decorated with the PostSharp Actor aspect. The “messages” are implied by the Ping and GetCounter async methods. Whether the “message-ness” of the actor model should be abstracted away is certainly a point for discussion, but it does provide for easier programming within an OO language like C#.

From the output we see that 1) activation (construction) is performed on the caller’s thread, 2) the player’s methods are invoked on background threads, and 3) there is no thread affinity.
pingpong_sm

Validation

The compile-time validation performed when using the Actor aspect tries to ensure you do the right thing.

1. All fields must be private, and private state must not be made available to other threads or actors.

If we try to define the name field as public:

[Actor]
public class Player 
{
    public string name;
    private int counter;
    ...
} 

This results in the compiler error: Field Player.name cannot be public because its declaring class Player implements its threading model does not allow it. Apply the [ExplicitlySynchronized] custom attribute to this field to opt out from this rule.

The same holds true of a public property:

[Actor]
public class Player 
{
    ...
    public int Id { get; private set; }
    ...
}

This results in the compile-time error: Method Player cannot return a value or have out/ref parameters because its declaring class derives from Actor and the method can be invoked from outside the actor.

2. All methods must be asynchronous.

To PostSharp this means that method signatures must include the async modifier. If you try to return a Task from a non-async method, something like this:

 public Task<string> SayHello(string greeting)
 {
     return Task.FromResult("You said: '" + greeting + "', I say: Hello!");
 }

You’ll get a compiler error: Method Player cannot return a value or have out/ref parameters because its declaring class derives from Actor and the method can be invoked from outside the actor.

The async rule also means that you must ignore the standard compiler warning about using async when you don’t demonstrably need to, which is why the GetCounter method looks like this:

public async Task<int> GetCounter()
{
    return this.counter;
}

PostSharp will dispatch the method to a background task, so you should ignore the compiler warning: This async method lacks ‘await’ operators and will run synchronously. Consider using the ‘await’ operator to await non-blocking API calls, or ‘await Task.Run(…)’ to do CPU-bound work on a background thread.

If you remove the async modifier the Actor validation will fail. You can add an await, but it looks silly, and you shouldn’t await Task.FromResult anyway:

public async Task<int> GetCounter()
{
    return await Task.FromResult<int>(this.counter);
}

You can, however, write a synchronous method, which PostSharp will dispatch to a background thread. For example:

public void Ping(Player peer, int countdown)
{
    Console.WriteLine("{0}.Ping from thread {1}", this.name,
                      Thread.CurrentThread.ManagedThreadId);

    if (countdown >= 1)
    {
        peer.Pong(this, countdown - 1);
    }

    this.counter++;
}

This may be a good thing, but also possibly misleading, since at first glance a developer might assume the method is executed synchronously on the current thread.

Rock-Paper-Scissors

Next I tried the “Rock-Paper-Scissors” example as described here.

Here’s my implementation.

namespace Roshambo
{
    public enum Move
    {
        Rock,
        Paper,
        Scissors
    }

    [Actor]
    public class Coordinator
    {
        public async Task Start(Player player1, Player player2, int numberOfThrows)
        {
            Task.WaitAll(player1.Start(), Task.Delay(10), player2.Start());

            while (numberOfThrows-- > 0)
            {
                var move1Task = player1.Throw();
                var move2Task = player2.Throw();
                Task.WaitAll(move1Task, move2Task);

                var move1 = move1Task.Result;
                var move2 = move2Task.Result;

                if (Tie(move1, move2))
                {
                    Console.WriteLine("Player1: {0}, Player2: {1} - Tie!", move1, move2);
                }
                else
                {
                    Console.WriteLine("Player1: {0}, Player2: {1} - Player{2} wins!", move1, move2,
                        FirstWins(move1, move2) ? "1" : "2");
                }
            }
        }

        private bool Tie (Move m1, Move m2) {
            return m1 == m2;
        }

        private bool FirstWins(Move m1, Move m2)
        {
            return
              (m1 == Move.Rock && m2 == Move.Scissors) ||
              (m1 == Move.Paper && m2 == Move.Rock) ||
              (m1 == Move.Scissors && m2 == Move.Paper);
        }

    }

    [Actor]
    public class Player
    {
        private Random _random;
        private string _name;

        public Player(string name)
        {
            _name = name;
        }
        public async Task Start()
        {
            int seed = Environment.TickCount + System.Threading.Thread.CurrentThread.ManagedThreadId;
            _random = new Random(seed);
        }

        public async Task<Move> Throw()
        {
            return (Move)_random.Next(3);
        }

        public async Task<string> GetName()
        {
            return _name;
        }
    }
}

class Program
{
    static void Main(string[] args)
    {
        AsyncMain().Wait();
        Console.ReadLine();
    }

    private static async Task AsyncMain()
    {
        var coordinator = new Coordinator();
        var player1 = new Player("adam");
        var player2 = new Player("zoe");

        await coordinator.Start(player1, player2, 20);
    }
}

And the exciting results:
rps

A few things to note:

  • I passed a name to the Player constructor but then never used it again. As private state, to access the name you must follow the Actor message rules and use an async method. I wouldn’t want the Coordinator to repeatedly ask each Player for its name, but this could have been done once at play start.
  • Trying to uniquely seed a System.Random instance for each player was tricky, and my implementation is a hack. The Random class is not thread-safe, so while sharing a single static Random instance among Player actors is an option, having to perform my own locking around Random.Next calls seemed to violate the spirit of the actor model. The default seed for a Random instance is Environment.TickCount, which if called in close succession will likely return the same value. Using the current thread id as a seed is an alternative, but although PostSharp will ensure that Actor methods will be called on a background thread, there’s no assurance they’ll be different threads for different actor instances. My not-so-robust compromise was to take the sum of TickCount and thread id and cross my fingers. Including the dummy Task.Delay when waiting for the players to start helps.
  • The Coordinator here does not hold state, and its Start method will 1) tell the players to start, 2) tell the players to throw, and 3) announce the result.
  • The Player does hold non-shared state, and contains Start, Throw and GetName async methods. None of these methods is inherently asynchronous, so I see compiler warnings telling me to consider using the await operator. I could have made these methods synchronous, but as I said above I think it leads to some cognitive dissonance between the code you see and the underlying actor implementation.

Summary

Overall, despite some quirks, using the Actor aspect could be useful. It would be interesting to compare PostSharp’s Actor support with other .NET implementations, and I may try that some day.

PostSharpin’ – Part 1

I’ve been intrigued with PostSharp for some time. PostSharp is an AOP platform and works its magic at build time (for the most part). You apply an aspect and PostSharp does the IL weaving, via integration with MSBuild, to output an assembly with the injected functionality. The goal, as their home page banner says: “Eradicate boilerplate. Raise abstraction. Enforce good design.”

I worked on the DevForce framework for a number of years and we’d written several custom aspects to implement certain product features, but I’d never had a chance to play with some of the “ready-made” implementations in the PostSharp patterns library. Writing your own aspects can range from fairly easy to quite hard, but many of the out-of-the-box aspects in the patterns library seem to combine great functionality and ease of use. Of particular interest to me are the ready-made patterns for INotifyPropertyChanged support and threading. The patterns library also includes support for logging, exception handling and a few other patterns, but I’ll save those for another day.

To get started with PostSharp, install the package(s) from NuGet. You’ll also be prompted for license information during the install, but since I’m using the 3.2 alpha I signed up for a 45 day free trial of PostSharp Ultimate.

NotifyPropertyChanged

Nothing screams boilerplate more than INotifyPropertyChanged. In any .NET environment, data bound objects must implement INotifyPropertyChanged (or the PropertyChanged pattern) for changes to be seen by UI controls. This means raising the PropertyChanged event, and more importantly, losing the simplicity of automatic properties since property setters must raise PropertyChanged. This gets irritating quickly.

With PostSharp the solution is simple: just decorate the class with the NotifyPropertyChanged aspect, found in the Model Pattern Library.

You can decorate a base class too, and get the functionality you expect across its sub-types. If you’ve both implemented INotifyPropertyChanged and added the aspect (maybe in a complex inheritance hierarchy), PostSharp handles that too. PostSharp will add the PropertyChanged logic to the setters of all public properties, but you can opt-out too by decorating a property with the IgnoreAutoChangeNotification aspect.

Here’s a simple class and sub-class with full INotifyPropertyChanged functionality:

[NotifyPropertyChanged]
public class Customer
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public string FullName
    {
        get { return string.Format("{0} {1}", FirstName, LastName); }
    }

    [IgnoreAutoChangeNotification]
    public DateTime LastContactDate { get; set; }
}

public class GoldCustomer : Customer 
{
     public int Points { get; set; }
}

Under the hood the aspect will inject the INotifyPropertyChanged logic into your IL. Actually, it implements a PostSharp interface called INotifyChildPropertyChanged, which in turn extends INotifyPropertyChanged.

This simplicity does come with a performance penalty, however. In my tests setting a single string property on a class implementing INotifyPropertyChanged (INPC) versus one using the NotifyPropertyChanged aspect, the INPC implementation was about 100x faster. So, while the aspect is a great solution for eliminating the boilerplate, for classes which won’t be data bound in the UI or which have strict performance requirements, it’s not an ideal solution.

Threading

The PostSharp Threading Pattern Library contains several interesting aspects, with more coming in the 3.2 release.

Background and Dispatched

The Background aspect can be applied to any method to dispatch it to the background. Under the hood PostSharp does a Task.Start to invoke your method on a background thread. With the async/await support in .NET 4.5 this may not be all that handy, but if you’re using a BackgroundWorker or working directly with the Thread or ThreadPool classes it may make your code a bit cleaner. Likewise, the Dispatched aspect will ensure the decorated method is invoked on the UI thread. Background and Dispatched don’t need to be used together, and using Dispatched can clean up some ugly BeginInvoke logic.

Coincidentally, I was just reading the April issue of MSDN Magazine and Laurent Bugnion’s article Multithreading and Dispatching in MVVM Applications, so switched his simple non-MVVM starting solution to use Background and Dispatched. Bugnion uses the DispatchHelper from MvvmLight in his MVVM samples; you can use these PostSharp aspects in your view models too, but unlike some of the other PostSharp libraries which have portable class library support, the threading library is available for .NET 4 and above only.

Here’s a snippet of the sample code from the article using Background and Dispatched:

[Background]
private void StartSuccessClick(object sender, RoutedEventArgs e)
{
    // This is a background operation!

    var loopIndex = 0;

    while (_condition)
    {
        // Do something

        // Notify user
        UpdateStatus(string.Format("Loop # {0}", loopIndex++));

        // Sleep for a while
        Thread.Sleep(500);
    }
}

[Dispatched]
private void UpdateStatus(string msg)
{
    StatusTextBlock.Text = msg;
}

These are handy but not all that compelling, since an InvalidOperationException is thrown immediately when you try to access a UI control on a background thread, and therefore easy to diagnose and fix. Much more insidious are thread safety problems. In a multi-threaded environment, safely working with mutable objects can be challenging: thread safety issues generally appear as odd “random” errors and deadlocks, often only under load, and are very difficult to reproduce and debug.

PostSharp defines three threading models or patterns and corresponding aspects: Thread Unsafe, Read-Writer Synchronized and Actor. (I’ll take a look at Actor in a follow-on post.)

ThreadUnsafe
If a single instance of a class should never be accessed concurrently, decorate the class with the ThreadUnsafe aspect. Should you access the object across concurrent threads, you’ll receive an immediate ConcurrentAccessException from PostSharp.

Markup is easy:

[ThreadUnsafe]
public class Booking
{
    public string CustomerName { get; set; }
    public DateTime StartTime { get; set; }
    public int NumberOfPersons { get; set; }
}

The ThreadUnsafe aspect also allows you to set a ThreadUnsafePolicy, such as ThreadAffine, which gives thread affinity to your objects and will cause a ThreadMismatchException to be thrown if the object is used on any thread other than the creating thread. Also baked into ThreadUnsafe is some compile-time validation and support for opting out to perform your own explicit synchronization.

Most classes aren’t designed to be thread safe, and don’t need to be, but if you have any globally shared objects or need to pass an object around among threads, or alternately, ensure it’s never shared across threads, this aspect is far easier to use than performing your own locking. I didn’t look at performance here, but I’ll take a quick exception over data corruption any day.

ReaderWriterSynchronized

Finally, dealing with thread-safe objects. When you do have objects which truly must be shared in a multi-threaded environment dealing with thread safety can be a big pain. First deciding on whether to use a lock, a mutex, a ReaderWriterLock, Interlocked variables, etc., and then what the scope should be. Once it’s finally working correctly a later modification “forgets” to lock the resource, and you don’t discover this until you’re in production under heavy load.

PostSharp handles this declaratively with its ReaderWriterSynchronized aspect. Under the hood it’s an implementation of ReaderWriterSynchronizedSlim, and provides for concurrent reads and exclusive writes. Here you decorate the class with ReaderWriterSynchronized, but must also mark methods, getters and setters with either Reader or Writer aspects. (Prior to PostSharp 3.2 these aspects were called ReaderLock and WriterLock.) The advantage of the aspect, other than the removal of all the locking code, is that PostSharp will immediately detect when a resource is accessed without a lock and throw a LockNotHeldException.

Here’s an example of the .NET sample for a SynchronizedCache using PostSharp aspects:

[ReaderWriterSynchronized]
public class SynchronizedCache
{
    private Dictionary innerCache = new Dictionary();

    [Reader]
    public string Read(int key)
    {
        return innerCache[key];
    }

    [Writer]
    public void Add(int key, string value)
    {
        innerCache.Add(key, value);
    }

    [UpgradeableReader]
    public AddOrUpdateStatus AddOrUpdate(int key, string value)
    {
        string result = null;
        if (innerCache.TryGetValue(key, out result))
        {
            if (result == value)
            {
                return AddOrUpdateStatus.Unchanged;
            }
            else
            {
                innerCache[key] = value;
                return AddOrUpdateStatus.Updated;
            }
        }
        else
        {
            innerCache.Add(key, value);
            return AddOrUpdateStatus.Added;
        }
    }

    [Writer]
    public void Delete(int key)
    {
        innerCache.Remove(key);
    }

    public enum AddOrUpdateStatus
    {
        Added,
        Updated,
        Unchanged
    };
}

In part 2 I plan to take a look at PostSharp’s Actor support, along with the new Recordable aspect for undo/redo and the Immutable and Freezable aspects, available in the upcoming 3.2 release.