I recently co-authored an article with Gael Fraiteur (creator of PostSharp) on how AOP frameworks such as PostSharp can be used to automate the implementation of common design patterns in .Net.
The article is now available to view on the InfoQ website here. A more offline friendly PDF version is also available here and from PostSharp’s brand new site.
Hope you enjoy what we have to say on the topic, and please don’t hesitate to give us your feedbacks!
Whilst searching for an elegant solution to apply string interning across a large number of classes (we’re talking about hundreds of classes here..) it dawned on me that I can achieve this with ease using PostSharp’s LocationInterceptionAspect. All I needed was something along the lines of:
You can apply this attribute to a class or even a whole assembly and it’ll ensure every piece of string constructed is interned, including string properties and fields defined by its subclass, which is exactly what I was after.
For example, take this trivial piece of code:
If you inspect the compiled code for the Base class in ILSpy you will see something along the lines of:
notice how the setter for BaseStringProperty has been modified to invoke the OnSetValue method defined in our aspect above as opposed to the setter method. In this case, it’ll call the String.Intern method to retrieve a reference to an interned instance of the string and set the property to that reference.
For more details on PostSharp’s interception aspects, I recommend reading Dustin Davis’s excellent posts on the topic:
PostSharp Principles: Day 7 Interception Aspects – Part 1
PostSharp Principles: Day 8 Interception Aspects – Part 2
As we’ve specified the multicast inheritance behaviour to multicast the attribute to members of the children of the original element, the string properties defined in both A and B classes are also subject to the same string interning treatment without us having to explicitly apply the InternAttribute on them:
What’s more, this attribute also works with F# types too, including record and discriminated unions types. Take for instance:
If you look at the generated C# code for the discriminated union type, the internal MyDuType.CaseB type would look something like the following:
notice how the two internal item1 and item2 properties’s setter methods have been modified in much the same way as the C# examples above? The public Item1 and Item2 properties are read-only and get their values from the internal properties instead.
Indeed, when a new instance of the CaseB type is constructed, it is the internal properties whose values are initialized:
Finally, let’s look at the record type, which interestingly also defines a non-string field:
because we have specified that the InternAttribute should only be applied to properties or fields of type string (via the CompileTimeValidate method which is executed as part of the post-compilation weaving process as opposed to runtime), so the internal representation of the Age field is left unaltered.
The Name field, however, being of string type, was subject to the same transformation as all our other examples.
I hope this little attribute can prove to be useful to you too, it has certainly saved me from an unbearable amount of grunt work!
NOTE: if you’re unfamiliar with how PostSharp works under the hood, I highly recommend that you check out Dustin Davis’ excellent PostSharp Principles series of blog posts here.
The new async/await keywords in C# are pretty awesome, and makes life an awful lot easier when writing asynchronous and non-blocking IO code. However, for those of us who are using frameworks such as PostSharp to deal with cross-cutting concerns we now face a new challenge – the aspects which we have come to rely upon no longer works the way we expect them to when applied on async methods (which returns void, Task or Task<T>), as can be seen from the examples below:
So what’s wrong here?
If you take a look at the code from the above example using a decompiler such as JetBrain’s DotPeek, you’ll see that the normal synchronous version of Foo looks something along the line of:
As you can see, the weaved code include calls to the OnEntry, OnSuccess and OnException methods provided by the OnMethodBoundaryAspect class, so everything is as expected here.
For FooAsync however, the picture is a little more complicated:
Turns out the C# compiler rewrites async methods into a state machine which means that although the OnSuccess and OnException hooks are still in place, they’re not telling us when the body of the method succeeds or fails but instead, when the state machine creation has succeeded or failed!
Pretty big bummer, eh?
One way (and the best way I can think of for now) to get around this is to have a special aspect which works with methods that return Task or Task<T> and hook up continuations to be executed after the returned tasks had finished. Something similar to the below will do for the on method boundary aspect:
And then you can create a TraceAsync attribute that works for async methods:
As you can see from the output above, our new OnTaskFinished, OnTaskFaulted and OnTaskCompletion hooks are correctly executed after the task returned by the async method had finished, faulted due to exception or ran to completion!
The same approach can also be applied to other built-in aspects such as the MethodInterceptionAspect class.
However, there are a two things you should consider first before jumping into the workaround proposed above.
1. if you look at the output from the previous example carefully, you’ll see that the line “FooAsync finished” came AFTER “Entering Boo” even though from the test code we have awaited the completion of FooAsync before calling Boo. This is because the continuations are executed asynchronously.
If this behaviour is not desirable to you, there is a very simple fix. Back in the OnAsyncMethodBoundAspect class we defined above, simply add TaskContinuationOptions.ExecuteSynchronously to each of the continuations:
2. the proposed solution still wouldn’t work with async methods that return void simply because there are no returned Task/Task<T> objects to hook up continuations with. In general though, you should avoid having async void methods as much as possible because they introduce some pitfalls which you really wouldn’t want to find yourself in! I’ve discussed the problem with aysnc void (and some potential workarounds) in a previous post here.
I hope this post proves useful to you, and happy PostSharp’ng! I hear some big things are coming in this space 
After watching Gael’s recent SkillsMatter talk on multithreading I’ve put together some notes from a very educational talk:
Hardware Cache Hierarchy
Four levels of cache
Data can be cached in multiple caches, and synchronization happens through an asynchronous message bus.
The latency increases as you go down the different levels of cache:
Memory Reordering
Cache operations are in general optimized for performance as opposed to logical behaviour, hence depending on the architecture (x86, AMD, ARM7, etc.) cache loads and store operations can be reordered and executed out-of-order:
To add to this memory reordering behaviour at a hardware level, the CLR can also:
The volatile keyword stops the compiler optimizations, that’s all, it does not stop the hardware level optimizations.
This is where memory barrier comes in, to ensure serial access to memory and to force data to be flushed and synchronized across all the local cache, this is done via the Thread.MemoryBarrier method in .Net.
Atomicity
Operations on longs cannot be performed in an atomic way on a 32-bit architecture, it’s possible to get partially modified value.
Interlocked
Interlocks provides the only locking mechanism at hardware level, the .Net framework provides access to these instructions via the Interlocked class.
On the Intel architecture, interlocks are typically implemented on the L3 cache, a fact that’s reflected by the latency associated with using Interlocked increments compared with non-interlocked:
CompareExchange is the most important tool when it comes to implemented lock-free algorithms, but since it’s implemented on the L3 cache, in a multi-processor environment it would require one of the processor to take out a global lock, hence why the contented case above takes much longer.
You can analyse the performance of your application at a CPU level using Intel’s vTune Amplifier XE tool.
Multitasking
Threads do not exist at a hardware level, CPU only understands tasks and it has no concept of ‘wait’. Synchronization constructs such as semaphores and mutex are built on top of interlocked operations.
One core can never do more than 1 ‘thing’ at the same time, unless it’s hyper-threaded in which case the core can do something else whilst waiting on some resource to continue executing the original task.
A task runs until interrupted by hardware (I/O interrupt) or OS.
Windows Kernel
A process has:
A thread is:
Threads can wait for dispatcher objects (WaitHandle) – Mutex, Semaphore, Event, Timer or another thread, when they’re not waiting for anything they’re placed in the waiting queue by the thread scheduler until it is their turn to be executed on the CPU.
After a thread has been executed for some time, it is then moved back to the waiting queue (via a kernel interrupt) to give some other thread a slice of the available CPU time. Alternatively, if the thread needs to wait for a dispatcher object then it goes back to the waiting state.
Dispatcher objects reside in the kernel and can be shared among different processes, they’re very expensive!
Which is why you don’t want to use kernel objects for waits that are typically very short, instead they’re best used when waiting for something that takes longer to return, e.g. I/O.
Compared to other wait methods (e.g. Thread.Sleep, Thread.Yield, WaitHandle.Wait, etc.) Thread.SpinWait is an odd ball because it’s not a kernel method, it resembles a continuous loop (it keeps ‘spinning’) but it tells a hyper-threaded CPU that it’s ok to do something else. It’s generally useful when you know the interrupt will happen very quickly and hence saving you from an unnecessary context switch. If the interrupt does not happen quickly as expected, the SpinWait will be transformed into a normal thread wait (Thread.Sleep) to avoid wasting CPU cycles.
.Net Framework Thread Synchronization
The lock Keyword
Good performance if low contention.
Design Patterns
This is where the PostSharp multithreading toolkit comes to the rescue! It can help you implement each of these patterns automatically, Gael has talked more about the toolkit in this blog post.
