Having a proper abstraction for asynchronous tasks makes it easier to coordinate multiple asynchronous activities. Once the first task has been initiated, the TPL allows you to compose a number of tasks together into a cohesive whole using what are called continuations . Look at the following code:

Task<string> task = Task.Factory.StartNew(() =>
{
WebClient client = new WebClient();
    return client.DownloadString("http://bing.com");
});

task.ContinueWith(webTask =>
    {
Console.WriteLine(webTask.Result);
    });

Every task object has the .ContinueWith method, which lets you chain another task to it. This continuation task will begin execution once the first task is done. Unlike the previous example, where we relied on the .Result method to wait until the task was done—thus potentially holding up the main thread while it completed—the continuation will run asynchronously. This is a better approach for composing tasks because you can write tasks that will not block the UI thread, which results in very responsive applications.

Task composability does not stop at providing continuations though, the TPL also provides considerations for scenarios, where a task must launch a number of subtasks. You have the ability to control how completion of those child tasks affects the parent task. In the following example, we will start a task, which will in turn launch a number of subtasks:

int[] numbers = { 1, 2, 3, 4, 5, 6 };

varmainTask = Task.Factory.StartNew(() =>
    {
        // create a new child task
foreach (intnum in numbers)
        {
int n = num;
Task.Factory.StartNew(() =>
                {
Thread.SpinWait(1000);
int multiplied = n * 2;
Console.WriteLine("Child Task #{0}, result {1}", n, multiplied);
                });
        }
    });
mainTask.Wait();
Console.WriteLine("done");

Each child task will write to the console, so that you can see how the child tasks behave along with the parent task. When you execute the previous program, it results in the following output:

Child Task #1, result 2
Child Task #2, result 4
done
Child Task #3, result 6
Child Task #6, result 12
Child Task #5, result 10
Child Task #4, result 8

Notice how even though you have called the .Wait() method on the outer task before writing done, the execution of the child task continues a bit longer after the task is concluded. This is because, by default, child tasks are detached, which means their execution is not tied to the task that launched it.

int n = num;
Task.Factory.StartNew(() =>
    {	
int multiplied = n * 2;

You do however have the option to mark a child task as Attached, as follows:

Task.Factory.StartNew(
    () =>DoSomething(),
TaskCreationOptions.AttachedToParent);

The TaskCreationOptions enumeration has a number of different options. Specifically in this case, the ability to attach a task to its parent task means that the parent task will not complete until all child tasks are complete.

Other options in TaskCreationOptions let you give hints and instructions to the task scheduler. From the documentation, the following are the descriptions of all these options:

The best part about these options, and the way the TPL works, is that most of them are merely hints. So you can suggest that a task you are starting is long running, or that you would prefer tasks scheduled sooner to run first, but that does not guarantee this will be the case. The framework will take the responsibility of completing the tasks in the most efficient manner, so if you prefer fairness, but a task is taking too long, it will start executing other tasks to make sure it keeps using the available resources optimally.

Error handling in the world of tasks needs special consideration. In summary, when an exception is thrown, the CLR will unwind the stack frames looking for an appropriate try/catch handler that wants to handle the error. If the exception reaches the top of the stack, the application crashes.

With asynchronous programs, though, there is not a single linear stack of execution. So when your code launches a task, it is not immediately obvious what will happen to an exception that is thrown inside of the task. For example, look at the following code:

Task t = Task.Factory.StartNew(() =>
{
    throw new Exception("fail");
});

This exception will not bubble up as an unhandled exception, and your application will not crash if you leave it unhandled in your code. It was in fact handled, but by the task machinery. However, if you call the .Wait() method, the exception will bubble up to the calling thread at that point. This is shown in the following example:

try
{
t.Wait();
}
catch (Exception ex)
{
Console.WriteLine(ex.Message);
}

When you execute that, it will print out the somewhat unhelpful message One or more errors occurred, rather than the fail message that is the actual message contained in the exception. This is because unhandled exceptions that occur in tasks will be wrapped in an AggregateException exception, which you can handle specifically when dealing with task exceptions. Look at the following code:

catch (AggregateException ex)
{
foreach (var inner in ex.InnerExceptions)
    {
Console.WriteLine(inner.Message);
    }
}

If you think about it, this makes sense, because of the way that tasks are composable with continuations and child tasks, this is a great way to represent all of the errors raised by this task. If you would rather handle exceptions on a more granular level, you can also pass a special TaskContinuationOptions parameter as follows:

Task.Factory.StartNew(() =>
    {
        throw new Exception("Fail");
    }).ContinueWith(t =>
        {
            // log the exception
Console.WriteLine(t.Exception.ToString());
        }, TaskContinuationOptions.OnlyOnFaulted);

This continuation task will only run if the task that it was attached to is faulted (for example, if there was an unhandled exception). Error handling is, of course, something that is often overlooked when developers write code, so it is important to be familiar with the various methods of handling exceptions in an asynchronous world.

Another reason that it is helpful to think of the way the compiler rewrites async methods with tasks and continuations, is because it keeps the fact that the TPL is in use to the fore. This means that you can use the new keywords in tandem with all of the existing features of the tasks in order to parallelize your application to match your requirements. This is important to remember, because you may be missing opportunities for parallelism, if you use the await keyword every time.

In the following example, we are calling an asynchronous method twice. The method returns Task<string>, so instead of calling await, which would (logically) hold execution of the second task until the first one was completed, we put the return values into variables, and use the Task.WhenAll method to wait until they both complete as follows:

private async void Sample_04()
{
    Task<string>firstTask = GetAsyncString("first task");
    Task<string>secondTask = GetAsyncString("second task");

    await Task.WhenAll(firstTask, secondTask);

Console.WriteLine("done with both tasks");
}

public async Task<string>GetAsyncString(string value)
{
Console.WriteLine("Starting task for '{0}'", value);

    await Task.Delay(1000);

    return value;
}

This allows both tasks to execute at the same time, and still gives you the ability to compose your program using the await keyword.

Error handling with asynchronous methods is very straightforward. Because the C# compiler is already rewriting the method entirely to await the completion of the task at hand before continuing, it lets you use the same exception based error handling methods that you have been using since C# 1.0.

The following is an example of an async method that throws an exception from Task:

private async Task ThisWillThrowAnException()
{
Console.WriteLine("About to start an async task that throws an exception");

    await Task.Factory.StartNew(() =>
    {
        throw new Exception("fail");
    });
}

As we discussed in the Error handling with tasks section, if you were interacting with the return value of this method as a regular task, then the exception would not be directly raised in the same context as the calling code. Either it will be raised when you call the .Wait method on the task, or you can handle it in a special continuation. But if you use await with the method, then you can wrap the code in a try/catch block as follows:

try
{
    await ThisWillThrowAnException();
}
catch (Exception ex)
{
Console.WriteLine(ex.ToString());
}

Execution of this code will seamlessly transition to the catch block when the unhandled exception is raised from the async method. This means that you don't really have to think about how you are going to handle exceptions if they are thrown from an asynchronous context, you simply catch them as you would if it was regular synchronous code.

Up to this point, we have just been discussing the mechanics of the asynchronous programming features that have been released in .Net 4.0 and C# 5.0. However, the significance of making parallel software applications easy to program deserves to be highlighted once again. There are several factors that highlight the importance of these new developments.

The First is Moore's law, which famously states that the number of transistors in CPUs is likely to double every year. While this law held true for many years, over the last decade some practical limits in cost and heat have been reached, with what is commercially possible on a single CPU. As a result, manufacturers began making computers with multiple CPUs. These new designs still manage to keep up with the prediction of Moore's law, but programs have to be specifically written to take advantage of the hardware.

Another huge factor in the impact of async is the rise of distributed computing. These days it is becoming more and more popular to architect programs as individual programs running on multiple computers. These peer-to-peer or client-server architectures are rarely CPU-bound, because of the latency in communicating between one computer and another over the network (or Internet). When faced with this kind of architecture, it becomes very very important to be able to parallelize the computation so that the user interface is not left waiting for a network call to complete.

Moving forward, software applications that take advantage of opportunities to use parallelism will be the ones that are superior in performance and usability. Many of the largest Internet companies, such as Google, are already taking advantage of massive parallelization, to tackle very large problems that simply would not be computationally possible on a single computer. The async keyword makes it so that you almost do not have to think about how and when you take advantage of it (almost).

One interesting newcomer to the framework is the TPL DataFlow library, which aims to improve the architecture of your applications. The NuGet description for the library describes the library:

It can be installed via NuGet by searching for TPL DataFlow, or visiting the NuGet site at https://nuget.org/packages/Microsoft.Tpl.Dataflow.

As stated in the description, data flow builds on top of the Task Parallel Library, a trend that I trust you are starting to see in this release, where the TPL, and by extension async/await of C# 5, help you parallelize your programs; it does so without any prescription of how to structure your application at a higher level. In contrast, the TPL DataFlow library provides various building blocks for communication between disparate parts of an application.

TPL DataFlow introduces two interfaces, which like IEnumerable are both simple and quite deep in their implications. The following diagram shows these interfaces:

We start with the ITargetBlock<T> , which is a block of code that will process a number of posted messages. You will primarily interact with it by calling the .Post method to post a message to the block. The other side of the equation is the ISourceBlock<T>, which acts as a source of data. Together, these interfaces, and the concrete implementations that ship with the TPL DataFlow library, help you create applications that are structured into discrete producers, and consumers.

The ActionBlock<T> block is the simplest implementation of the ITargetBlock<T>. It accepts a delegate in the constructor that defines what action will be taken when a message is posted to it. The following is how you define a simple block that accepts a string and writes it to the console:

var block = new ActionBlock<string>(s =>
{
Console.WriteLine(s);
});

Once you have defined the block, you can start posting messages to it. The action block executes asynchronously, which is not a requirement, just to show how this implementation handles the posting of messages. Look at the following code:

for (inti = 0; i< 30; i++)
{
block.Post("Processing #" + i.ToString());
}

Here we see a very simple loop that iterates 30 times and posts a string to the target action. Once you have defined the target block, you can use a number of different implementations of source blocks that come with the TPL DataFlow library to create very interesting routing scenarios.

One such ISourceBlock<T> that you will find quite useful is the TransformBlock<T, K> block. As the name suggests, the transform block lets you take in one kind of data, and potentially transform it into another. In the following example, we will create two blocks; the TransformBlock will take an integer and convert it to a string. The resulting output will then be routed to ActionBlock, which accepts a string for processing. Look at the following example code:

TransformBlock<int, string> transform = new TransformBlock<int, string>(i =>
    {
        // take the integer input, and convert to a string
        return string.Format("squared = {0}", i * i);
    });

ActionBlock<string> target = new ActionBlock<string>(value =>
    {
        // now use the string generated by the transform block
Console.WriteLine(value);
    });

transform.LinkTo(target);

Input and output types for the transform block are designated in the form of generic parameters. You add the action block to the end of the data flow chain by using the .LinkTo method, which directs all the output of the source block to the target. This is explained in the following code:

for (inti = 0; i< 30; i++) transform.Post(i);

When you post an integer to the transform block, you will see that the message first flows through the transform block, and is then routed to the action block.

Another kind of source block shown in the following diagram, which can help you process a stream of information, is a batch block:

Usually this kind of batch processing can be useful if there are certain costs associated with the processing of each message, such as informational lookups to a database. Many times in cases like this, you can batch up the query values and do a single database lookup for multiple messages at a time and amortize the cost of the lookup as you increase the batch size. Look at the following example:

var batch = new BatchBlock<string>(5);

var processor = new ActionBlock<string[]>(values =>
    {
Console.WriteLine("Processing {0} items:", values.Length);
foreach (var item in values)
      {
Console.WriteLine("	item: {0}", item);
      }
    });

batch.LinkTo(processor);

for (inti = 0; i< 32; i++)
{
batch.Post(i.ToString());
}

You can think of the batch block as a specific kind of transform block that takes a single instance of a message in the frontend, waits until a specified number of these messages have arrived, and then delivers that group as an array to the target block. This can be useful when you have a system that has to do some setup, such as looking up reference data for every message that it receives. If you can process many messages in one batch, then the cost of the initialization can be amortized over time. The more messages you process, the lower the cost. The following example shows how this is achieved:

// manually trigger
batch.TriggerBatch();

You can also manually trigger a batch if you know that the threshold number of messages has not been reached. In this way, you can process a batch of a smaller size if your system has to process a message within a certain amount of time.

The broadcast block shown in the following diagram is an interesting source block:

The way it works is that you can link multiple target blocks to the broadcaster. When a message is posted to the broadcaster, it will diligently be delivered to every target. One obvious application of this block is to write a server application that has to service multiple clients at the same time. Each client is then represented by a target block that gets linked to the broadcaster. Whenever you need to notify every client, you can just post a message to the broadcaster. Look at the following example:

var broadcast = new BroadcastBlock<string>(value =>
{
    return value;
});

broadcast.LinkTo(new ActionBlock<string>(value =>Console.WriteLine("receiver #1: {0}", value)));
broadcast.LinkTo(new ActionBlock<string>(value =>Console.WriteLine("receiver #2: {0}", value)));
broadcast.LinkTo(new ActionBlock<string>(value =>Console.WriteLine("receiver #3: {0}", value)));
broadcast.LinkTo(new ActionBlock<string>(value =>Console.WriteLine("receiver #4: {0}", value)));

broadcast.Post("value posted");

In this example, we link four separate action blocks. When we post value posted, we will see four separate verifications of receipt in the console output. In a way, this is very similar to the existing event system in the C# language.

To take advantage of the new async/await features, some very core features of the .NET Framework have evolved. Namely, the I/O features including streams, network, and file operations. This is huge because, as mentioned previously, I/O bound operations are coming to dominate the execution time of a modern application. So any improvements in the API to deal with those operations can be seen as a good sign.

At the lowest level are additions to the Stream API. Since .NET 1.0, this has been one of my favorite abstractions because it can be used in so many different ways. Reading and writing to a file, or a network socket, or a database, all use the stream API to represent a series of bytes of unknown size. Of course, the limiting factor here has been that, depending on the stream implementation that you are using, the performance and latency can vary greatly. So you should not write code to a network stream in the same way as code that is written to an in-memory stream, because the performance will be vastly different.

With async though, this changes because the Stream class has received new awaitable versions of all of the methods in the class. In the following example, we write an asynchronous method that takes a set of numbers, and writes them to a string as follows:

private static async void WriteNumbersToStream(Stream stream, IEnumerable<int> numbers)
{   
StreamWriter writer = new StreamWriter(stream);

foreach (intnum in numbers)
    {
        await writer.WriteLineAsync(num.ToString());   
    }
}

Although code like this would have been possible to write in a similar fashion before, the addition of methods like .WriteLineAsync lets you write code that is simple without having to worry about the stream holding up execution of the calling thread.

Because of the underlying improvements in the stream API, other areas, such as reading and writing files have improved. Look at the following code:

private static async void WriteContentstoConsoleAsync(string filename)
{
FileStream file = File.OpenRead(filename);

StreamReader reader = new StreamReader(file);
    while (!reader.EndOfStream)
    {
        string line = await reader.ReadLineAsync();
Console.WriteLine(line);
    }
}

I honestly cannot tell you how many times I have seen variations of this method over the years, of course, written in a non-asynchronous way. Without asynchrony, this method would absolutely choke if you attempted to read a very large file. A perfect example of this is the Notepad application that has come with every version of Windows. If you try to open a very large file, be prepared to wait because the interface will be frozen while the file is streamed from the disk.

But with the asynchronous version here, the interface will not be bogged down, regardless of the size of the file. That is the great feature of async, it accepts the kind of code developers are likely to write, and makes it so that common performance issues, such as buffering, will not affect the performance of the application quite as much. This is a perfect example of the "Pit of Success".