Our never-ending mission to spread the word about using PostSharp to produce cleaner code finds Gael and I in the good ole U.S. of A. for a week of presentations at user groups and businesses in Ohio and Michigan.
Joe Kunk first contacted us about the idea earlier this year and, together with the undying help of David Giard, we were able to build a tour that combines 4 user groups, 3 businesses, and 1 university over a 5 day stretch of interstate travel.
We sprinkled-in some customer visits for good measure, and added an extended layover at TechEd Europe on the way back to Prague and voilà: the perfect summer tour.
Gael has two presentations prepared for the tour:
- “Multithreading Beyond the Lock Keyword.” Dusting-off low-level synchronization primitives, Gael shows how to design programs that make better use of multiple cores. Because playing directly with low-level primitives can be overly complex, you’ll discover how large-scale multi-core software can be simplified using design patterns and how some these patterns can be ultimately simplified using aspect-oriented programming.
- “Intro to Aspect-Oriented Programming (AOP) with PostSharp.” Gael speaks about the problem with conventional programming, gives a gentle introduction to AOP with PostSharp, demonstrates how it works and why you should use it to eliminate scattered, tangled and coupled code from your codebases.
We’re excited to connect with user group leaders, members, and area businesses in Cleveland, Toledo, Detroit and Lansing. We look forward to learning about your current projects, the insight you provide about the solutions you’re looking for, and any feedback you can give about how you’re using PostSharp and our new toolkits.
Tour dates and locations include:
TechEd Europe promises to be one of the summer highlights, connecting us with new and old friends alike. Many thanks to Sara Faatz and the DevExpress team for their generosity. We’re very excited to get to know you and your team better. To our old friend Brady Gaster , who will be in Amsterdam to support the Azure team and participate in some breakout sessions, our apologies in advance to your liver.
If you find yourself in Ohio or Michigan next week, or attending TechEd Europe 2012 at the end of the month, please don’t hesitate to contact me to arrange a meet-up. Here’s to another wonderful summer!
Happy PostSharping!
-britt
p.s. – check out our Community page to find other opportunities to learn about PostSharp this summer.
Red Gate and SharpCrafters are happy to announce that SmartAssembly – an obfuscator that protects your application against reverse-engineering, cracking and modifications – now genuinely supports PostSharp.
The Darkness
Prior to PostSharp 2.0, running an obfuscator on assemblies enhanced by PostSharp would almost certainly cause runtime issues. The reason, as Simon Cooper explains extensively in his blog, is that PostSharp includes textual references to methods, and these references are broken when the obfuscator renames these methods.
The Battle
PostSharp 2.1 attempted to solve this limitation with a feature called “obfuscation awareness”, which emits additional data structures that could be parsed and re-written during or after the obfuscator. We implemented a post-obfuscation utility that fixed the obfuscated assembly – with initial support for the gorilla in the room: Dotfuscator. Quite frankly, we were quite disappointed by this effort, first because we’ve never received the kickback we hoped from Preemptive, then because the high price point of their product turned people away. Additionally, the post-obfuscation step caused additional friction. So, this feature was a semi failure. Up to now.
The Light
We’re thrilled to announce that the good folks at Red Gate have baked support for PostSharp right into SmartAssembly (>=6.6.4). No need for an additional build step, a sweeter price point, and a friendly relationship: we and our customers have many reasons to be satisfied!
Just remember to enable PostSharp obfuscation awareness in each project that requires it:
Happy PostSharping!
-gael
We’ve got great news for those of you who have been waiting patiently for a PostSharp online training course to become a reality:
Pluralsight, the online training provider for hardcore developers, announced this week the availability of the PostSharp Fundamentals course authored by senior software developer, trainer, and PostSharp MVP – Donald Belcham.
The course is an introduction to using PostSharp and covers all the fundamentals needed to effectively use it to create basic aspects in your applications. The course includes:
- Introduction (Why and How to use Aspect-Oriented Programming)
- Installation (EXE & MSI, NuGet, Source Control, License Management)
- Out of the Box Aspects (OnMethodBoundaryAspect, OnExceptionAspect, EventInterceptionAspect, etc.)
- Aspect Lifetime (Compile Time, Serialization & Deserialization, Run Time)
- Existing Codebases (Approach, Attaching Aspects, Side Effects, Low Hanging Fruit)
- Deployment (Deployables, Signing Assemblies, Obfuscation)
- Developer Experience (Debugging, IDE Enhancements)
Many thanks to Aaron Skonnard and his team at Pluralsight for continuing to deliver quality online training from some of today’s leading .NET developers. Also a big congratulations and thanks to our good friend Donald Belcham for his continuing efforts to spread the word about the benefits of using PostSharp for AOP.
Watch Donald’s PostSharp Fundamentals course on Pluralsight >>
Last week, we announced the pre-release of PostSharp Threading Toolkit, a library of aspects implementing best-practice patterns of multithreaded applications. The toolkit is available on NuGet and its source code is hosted on GitHub.
Note: the source code of the ping-pong example is available on GitHub too.
The Right Level of Abstraction
The motto of this toolkit is that direct use of the System.Threading namespace brings so much complexity that it cannot scale to large object models. In other words, if you’re using System.Threading or just locks in your business or UI layer (except in a few very specific classes), you are probably addressing the threading concern at the wrong level of abstraction, and you and your co-workers will perhaps have difficulties to handle that complexity in large applications.
A far better approach to multithreading is to grab a few threading models and to make sure everyone understands them. Then, select the proper threading model for every part of your application (UI and domain will probably require a different threading model). Finally, implement the threading model in all your classes. That final step is obviously the most complex and time-consuming (there can be thousands of classes) and cancels the benefits of abstraction – unless you are getting the tools for the job: Erlang, F#, or… PostSharp Threading Toolkit.
The Bad: Mutable Shared State
Imagine you have a room full of accounting assistants all working on the yearly balance of the same company. To make it easier to share information among workers, the manager thought it was smart to decide that all accounts will be maintained on a blackboard, so that many workers can update it simultaneously. (I chose a blackboard on purpose, because if whiteboards existed, they would probably have chosen a computer.)
It’s clear that workers of this team need to cooperate (i.e., communicate) in order to get their jobs done, otherwise they are going to overwrite each other’s accounting lines and mess with the balance.
The moral in the fable: concurrent access by several workers to shared mutable state causes mess.
A state (typically: a field or an element array) is mutable if it can be modified. It is shared if it can be read or updated by several workers concurrently. Immutable shared state does not cause conflict (all workers can concurrently look at the President’s picture on the wall). Private mutable state is safe too (there would be no issue if every worker was assigned a single account).
Actors Against Mutable Shared State
Actor-Based Programming (or simply actors) address the problem of multithreaded software by eradicating mutable shared state. Formally, the Actor model wants to ensure that, for any state:
NOT (state is mutable AND state is shared).
In other words, the Actor model ensures that:
state is mutable XOR state is shared.
The Actor model implements these restrictions using – guess what: actors! Think of as Actor as an object-oriented class (with some children objects such as collections, perhaps).
The Actor model is based on the following principles:
- Actors communicate between each other and with the rest of the world using messages.
- Messages are immutable.
- An actor process only one message at a time.
- Processing messages may cause a change of the state of the actor that processes it. Other state changes must be ordered through message passing.
The principles ensure that the only mutable state is private to an actor, and since the message-passing mechanism guarantees actors are single-threaded, the mutable state is not shared among different processors.
These simple principles are at the origin of the success of Erlang and F#, but have traditionally been difficult to implement in C#. With the new C# 5.0 and PostSharp Threading Toolkit, this is now much easier!
A Simple Ping-Pong Game
Let’s see these principles in action on the simplest multi-actor game invented: ping-pong. To make the game a little more interesting (and show that execution is actually asynchronous), I’m throwing two balls in the game.
class Player : Actor
{
string name;
int counter;
public Player(string name)
{
this.name = name;
}
public void Ping(Player peer, int countdown)
{
Console.WriteLine("{0}.Ping from thread {1}", this.name,
Thread.CurrentThread.ManagedThreadId);
if (countdown >= 1)
{
peer.Ping(this, countdown - 1);
}
this.counter++;
}
}
class Program
{
static void Main(string[] args)
{
Player ping = new Player("Sarkozy");
Player pong = new Player("Hollande");
ping.Ping(pong, 4);
ping.Ping(pong, 4);
Console.ReadLine();
}
}
This program gives the following output:
Sarkozy.Ping from thread 3
Sarkozy.Ping from thread 3
Hollande.Ping from thread 4
Hollande.Ping from thread 4
Sarkozy.Ping from thread 3
Sarkozy.Ping from thread 3
Hollande.Ping from thread 4
Hollande.Ping from thread 4
Sarkozy.Ping from thread 6
Sarkozy.Ping from thread 6
As you can see, actors run on a different thread than the Main method. Calling the Ping method results in a message to be appended to the actor’s message queue. When a message queue was empty and got its first message, the dispatcher creates a Task to process the message queue. Therefore, actors run on the thread pool and there’s no need to have one thread per actor.
Note that the field Player.counter is incremented by the Ping method. Incrementing consists in reading and writing a field atomically. In a concurrent environment, we should have used Interlocked.Increment. But since the field is private to the actor, we don’t have to think about data races.
Build-Time Validation
I’ve said that the Player.counter field is safe because it’s private. I meant that logically it belongs to the private state of the actor, as opposed to the state that is shared among actors and threads. That said, private is also a C# concept, so what if the field was public?
We thought about this issue, and we designed the toolkit to minimize the level of thinking necessary to apply a threading model, so the toolkit will warn you of any potential error with the following build-time error message:
1>------ Build started: Project: TestAsync, Configuration: Debug Any CPU ------
1>POSTSHARP : postsharp error THR005: Field Player.counter must be private or
protected because the Player class is an Actor.
1>POSTSHARP : postsharp error PS0060: The processing of module "TestAsync.exe" was
not successful.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
The toolkit does not claim it’s smarter than you, but it prevents you (and more likely your co-workers) from obvious mistakes. If you decide that a public field is really what you want, you have to annotate the field with the [ThreadUnsafe] custom attribute, which opts out from the safety net enforced by the toolkit.
In a similar spirit, the toolkit will prevent an actor to expose public method that return a value or have ref or out parameters. Why? Because these methods are modified to run asynchronously, so output values could not be known at the time the asynchronous call completes (asynchronous means that the execution continues after the call completes).
If you think this is an awful limitation, you’re right. But we have some good news for you.
Where C# 5.0 Saves the Day
The C# feature of the year is the ability to work with asynchronous methods thanks to two new keywords: async and await. The async keyword basically allows the use of the await keyword, which suspends the execution of the method until some task (or anything “awaitable”) completes. This is exactly what we need to get actor methods return some output to the caller.
Suppose we want to add a GetCounter method to the Player class. We could simply do that:
public async Task<int> GetCounter()
{
return this.counter;
}
Intellisense gives some warning that there is no async keyword and the method will therefore run synchronously, but PostSharp adds some magic to make the method run asynchronously from the message queue of the Actor. You don’t have to take care of that and can safely ignore the compiler warning.
Now, suppose we call GetCounter just after we call Ping. The message is going to be queued just after the first Ping messages, we we’re probably going to get a counter value of 1. This is not what we want: we want to get the counter after the ping-pong game is finished. To achieve that, we need to make the Ping method awaitable by using the async and await keywords.
Here is the updated source code of our new ‘awaitable’ actor game:
class Player : Actor
{
string name;
private int counter;
public Player(string name)
{
this.name = name;
}
public async Task<int> GetCounter()
{
return this.counter;
}
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++;
}
[ThreadSafe]
public override string ToString()
{
return this.name;
}
}
class Program
{
static void Main(string[] args)
{
AsyncMain().Wait();
}
private static async Task AsyncMain()
{
Player ping = new Player("Sarkozy");
Player pong = new Player("Hollande");
Task pingTask = ping.Ping(pong, 4);
Task pongTask = pong.Ping(ping, 4);
await pingTask;
await pongTask;
Console.WriteLine("{0} Counter={1}", ping, await ping.GetCounter());
Console.WriteLine("{0} Counter={1}", pong, await pong.GetCounter());
}
}
Is PostSharp Necessary Anyway?
You could wonder where is PostSharp in this code. After all, isn’t C# 5.0 all you need? Actually, PostSharp is hidden behind the Actor class. It will modify the code of all public instance methods of actors to make them compatible with the Actor model. If you remove PostSharp, you will perhaps still have asynchronous methods, but they will not respect the Actor model and C# 5.0 alone isn’t going to clean up the multithreaded mess.
Actually, PostSharp adds the following code on the top of the main method of the asynchronous state machine. That seems complex, but it’s actually approximately equivalent to doing an “await Task.Yield()” if the code executes from the wrong context, to force it to be rescheduled in the right context.
if (!this.<>4__this.Dispatcher.CheckAccess())
{
this.<>t__dispatchAwaiter = Task.Yield().GetAwaiter();
SynchronizationContext oldContext = SynchronizationContext.Current;
SynchronizationContext.SetSynchronizationContext
(this.<>4__this.Dispatcher.SynchronizationContext);
this.<>t__builder.AwaitUnsafeOnCompleted<YieldAwaitable.YieldAwaiter,
Player.<GetCounter>d__0>(ref this.<>t__dispatchAwaiter, ref this);
}
else
{
// Your original code.
}
Additionally to adding behavior to public methods, PostSharp (the Threading Toolkit, more specifically) ensures that your source code respects some safety rules for the Actor model, and emits build-time errors or run-time exceptions if necessary.
To-Do List
Although the main functionalities are implemented and work fine, there is still a lot of work on the to-do list. For instance, the toolkit does not enforce dispatching of private interface implementation yet, neither callback methods (delegate). Not all build-time and run-time checking are already implemented. Specifically, we don’t check that all messages (method parameters and return values) are immutable or otherwise thread-safe.
Summary
I’ve shown how PostSharp Threading Toolkit, together with C# 5.0, offer a compelling implementation of the Actor threading model. As you can see, proper compiler support (PostSharp is a compiler extension) makes programming much easier because it allows to address a problem at the proper level of abstraction.
In later posts, we’ll talk about other threading models supported by PostSharp Threading Toolkit: reader-writer synchronized, and thread unsafe (or singlethreaded).
Happy PostSharping!
-gael