Task-Based Asynchronous Pattern in .NET 4.5 – Part 1

Tweet

In a previous article we saw an overview of the new IDE and Framework features of the current .NET Framework beta v4.5. Among other things .NET 4.5 has an improved support for Asynchronous programming through a new Task based model. In this article, we will take a look at the new async and await key words introduced in the C# language.

Asynchronous programming has always been considered a niche and has always been delegated as a ‘good-to-have’ in v2 of something that you were working with. Moreover lack of Async APIs meant you had to wrap async functionality first before you could use them in your code. Basically a lot of plumbing was potentially required to get off the ground with Async programming.

So the synchronous API for reading into a byte buffer would traditionally look as follows:

public class MyReader
  
{

  
    public int Read(byte [] buffer, int offset, int count);

  
}

The pre-TPL API would look something like the following and you would have to setup the callback method yourself and track the End[Operation].

public class MyReader
  
{

  
    public IAsyncResult BeginRead(

  
        byte [] buffer, int offset, int count, 

  
        AsyncCallback callback, object state);

  
    public int EndRead(IAsyncResult asyncResult);

  
}

Instead of the call-back model, one could use the Event based model and write it up as follows

public class MyReader
  
{

  
    public void ReadAsync(byte [] buffer, int offset, int count);

  
    public event ReadCompletedEventHandler ReadCompleted;

  
}

public delegate void ReadCompletedEventHandler(
  
    object sender, ReadCompletedEventArgs eventArgs);

public class ReadCompletedEventArgs : AsyncCompletedEventArgs
  
{

  
    public int Result { get; }

  
}

But with the introduction of Task Parallel Library (TPL), asynchronous programming became easier. To make the above, we would simply need the following code

public class MyReader
  
{

  
    public Task<int> ReadAsync(byte [] buffer, int offset, int count);

  
}

  

Now the above method signature shows how an Async method would be implemented. It returns a Task<T> where T is of type required for the return and the method itself by convention has the word Async appended to it.

Apart from the lesser plumbing required, the framework added a huge collection of Async methods by default. So going forward in this article, we will look at how to consume Async methods provided in the framework.

Consuming an Async call and the ‘async’/‘await’ keywords

As mentioned above the latest .NET framework provides a lot of Async counterparts of older Synchronous method calls. Specifically anything that could potentially take more than 100ms now has an Async counterpart. So how do we use these async methods?

In .NET 4.5 we use the async and await keywords while consuming Asynchronous APIs. So to consume the above ReadAsync we would write code as follows

The method signature when marked with async keyword tell the compiler of our intent to use Async method and that we wish to ‘await’ returning from these Async methods. So the compiler expects one more await keywords in the method. If none are provided, compiler will generate a warning.

Under the hood, the compiler generates a delegate for code after the await key word is used and moves execution to the end of the method such that the method returns immediately. Thereafter the delegate is called once the async method is complete.

Things to look out for

All looks pretty neat, where is the catch?

Well there are quite a few when leveraging the Async framework.

Synchronization Context

Though thread synchronization has now been hidden away from you, does not mean it’s not happening. For example an async read operation that is initiated from the UI thread will have a SynchronizationContext stashed away and every thread completion will result in a hop back to the initiation thread. This is a good idea most of the time because for end users the hop back means ability to show progress on the UI or work on the UI thread. However if this call is initiated from UI thread and passed on to a library whose sole purpose it to read the data asynchronously, the overhead for hopping back and forth between the execution thread and the UI thread is very high and big performance killer. To avoid this Sync context can be skipped using the following syntax

…
  
{

  
    …

  
    int bytesRead = await reader.ReadAsync(buffer, 0, buffer.Length).ConfigureAwait(false));

  
    …

  
}

What ConfigureAwait(false) does is, it tells the framework not to hop back into the initialization thread and continue if possible.

Avoiding Deadlocks

Incorrect use of the ‘Wait’ call instead of the synchronous ‘Await’ call may cause deadlocks because issuing a Wait on the initialization thread blocks the UI thread, and when ReadAsync tries to synchronize it can’t so it waits resulting in an unending wait. This situation can be avoided if we configure TPL to avoid synchronization context using the ConfigureAwait(false).

How Garbage Collection is affected

Use of the async keywords results in creation of an on-the-fly state machine structs that stashes away the local variables. Thus these local variables are ‘lifted’ up from the ‘stack’ allocation and moved into the heap. Hence even through they look like local variables they definitely stay around for longer.

Moreover .NET’s GC is generational and sometimes multiple sync points might push the allocated ‘locals’ into an older generation thus keep them around even longer before they are eventually collected.

Asynchronicity and Performance

Asynchronous operations are more about scaling and responsiveness rather than raw performance. Almost all asynchronous operations suffer a performance for a single operation due to the overheads introduced. Hence do not treat Performance as the criteria for doing async operations. True performance gain is an aggregate of how better your async implementation uses resource better.

Client vs. Server Async operations

Just as performance is not the reason to do Async, it may not be a good fit for server side operations either. On the client side, asynchrony is all about getting the UI thread freed up for user-interaction as soon as possible by pushing compute intensive tasks off it. But on Server side, operations deal with processing a request and responding to it as quickly as possible. There is no UI thread per se. Every thread is a worker thread and any thread blocked is an operation in wait. For example in ASP.NET the thread pool is revered resource. Unnecessary thread spinning by indiscriminately using threads increase CPU resource requirements and reduce server scaling. Remember in case of servers the most important thing to do is to avoid context switches. Choose an async operation wisely for example when you have I/O intensive operations, using async with correctly configured awaits will actually help the operation.

Going forward

This was a quick introduction to the basic features of the Task-Based Asynchronous Pattern in the upcoming framework release. We will explore more features of this implementation in a follow up article.

Tweet