Patterns for Asynchronous Composite Tasks in C#

In the previous two articles, I’ve explained why and how to use async/await for asynchronous programming in C#.

Now, we will turn our attention to more interesting things that we can do when combining multiple tasks within the same method.

Update 22nd September 2018: Another pattern not covered here is fire-and-forget. There are many ways to achieve this, including simply not awaiting (causes warnings – see ways to ignore them), using Task.Run(), using Task.Factory.StartNew(), or async void (not recommended, see “Common Mistakes in Asynchronous Programming with .NET“. This is suitable when you want to trigger some kind of processing but don’t care whether/when it completes. It doesn’t really fit the fast food scenario used in this article — placing an order without ever being notified of its completion/failure is sure to annoy customers. Which I suppose is also why applying for jobs is such a pain in the ass for many people.

Fast Food Example

In order to see each pattern at work, we need a simple example involving multiple tasks. Imagine you walk into your favourite fast food restaurant, and order a meal involving a burger, fries and a drink. Each of these takes a different amount of time to prepare, and the total time of the order may vary depending on how the execution of these three tasks takes place.

Sequential Tasks

The simplest approach is to just execute tasks one after another, waiting for one to finish before starting the next.

In this example code, we are representing the fries, drink and burger tasks as delays of different length. The rest of the code is purely diagnostic in order to allow us to get some output and understand the results. There is also a workaround allowing us to use asynchronous code in Main(), that was described in the previous article.

Here is the output from the above:

Fries completed after 00:00:03.0359621
Drink completed after 00:00:04.0408785
Burger completed after 00:00:09.0426927
Order completed after 00:00:09.0434057

Because we performed each task sequentially, the total order took 9 seconds. In a fast food restaurant, it probably does not make sense to wait for the fries to be ready before preparing the drink, and to wait for both to be ready before starting to prepare the burger. These could be done in parallel, as we will see in the next sections.

In this case, the tasks are dependent on each other. In order to get the content of the response, the response itself must first finish executing. Because there is this dependency, the tasks must be executed one after the other.

Parallel Tasks, All Must Finish

If we fire off the tasks without awaiting them right away, there are more interesting things we can do with them. Essentially, by removing await, we are running the tasks in parallel.

Aside from removing await before each task, we are assigning them to variables so that we can keep track of them. We then rely on Task.WhenAll() to wait until all tasks have completed (as an analogy, think of it as a memory barrier). Task.WhenAll() is awaitable, unlike its blocking cousin Task.WaitAll(). This gives us a way to easily run asynchronous tasks in parallel where it makes sense to do so.

And in a fast food restaurant, preparing fries and drink while the burger is cooking makes a lot of sense. In fact, the order is ready after just 5 seconds, which is the time of the longest task (the burger). Because the fries and drink were prepared concurrently with the burger, they did not add anything to the total time of the order.

Drink completed after 00:00:01.1696855
Fries completed after 00:00:03.0363008
Burger completed after 00:00:05.0443482
Order completed after 00:00:05.0445130

Note that Task.WhenAll() takes an IEnumerable<Task>, and as such, you can easily pass it a list of tasks (e.g. when the number of tasks is dynamic based on input or data).

Parallel Tasks, First To Finish

If you’re hungry and thirsty after an unexpected trip in the desert, it’s unlikely that you’re going to want to wait for all items to finish before starting to eat and drink. Instead, you’ll consume each item as soon as it arrives.

Task.WhenAny() will wait until the first task has completed, and then resume execution of the method. It also returns the task that completed (though we’re not using that here).

Drink completed after 00:00:01.0390588
Order completed after 00:00:01.0412190
Fries completed after 00:00:01.0413729
Burger completed after 00:00:01.0413729

Our results are a little messed up. Since Task.WhenAny() only waits for the first task to complete, the entire order was considered complete as soon as the drink was ready. The stopwatch was subsequently stopped, and the output shows 1 second for everything even though the fries and burger actually took longer.

This scenario is useful when you want to retrieve data from different sources and just use the result that arrived fastest. It is not very intuitive for when you’re dying of hunger and want to gobble up everything as it arrives. We’ll address this in the next section.

Parallel Tasks, All Must Finish, Process As They Arrive

So here’s the scenario: we’re famished, and we want to consume our drink, fries and burger as they are ready. We want to consume all of them, but Task.WhenAny() only gives us the first task that completed.

It’s easy to reuse Task.WhenAny() to wait for all tasks to complete, by using a simple loop.

From this example, it might appear that there’s no benefit from using this approach when compared to just using continuations on tasks and using Task.WhenAll(). However, in real scenarios that don’t involve french fries, it is often reasonable to check the result of each task for failure. If one of the tasks fails, then the operation is aborted without having to wait for all the other tasks to complete.

Task With Timeout

As it turns out, we’re so hungry that we’re only willing to wait up to 4 seconds for each item, since the start of the order. If they take longer than 4 seconds, we’ll cancel that part of the order.

Fortunately, there’s an excellent blog post on the Parallel Programming MSDN blog from 2011 that shows how to write a TimeoutAfter() method that does exactly this. I’ll go ahead and steal it:

Running this, the burger task will timeout and an exception will be thrown. Since we’re not actually checking for this, all we see in the output is that the burger task finished after 4 seconds instead of 5.