Simplifying Asynchronous Programming with Microsoft Visual Studio Async CTP Nelson Morais Universidade Lusófona de Humanidades e Tecnologias Campo Grande, 376 1749-021 Lisboa (Portugal) +351 91 732 46 26 nelsonmorais@yahoo.com ABSTRACT Asynchronous Programming Model (APM) and Event-based Asynchronous Programming (EAP) have always been harder to consume and implement than the Synchronous Programming Model (SPM). Although Microsoft.NET Framework supported asynchronous programming since the first version of the library, and continually improved its usage, current patterns still break the control flow of the code and force the usage of callbacks or lambda expressions. This paper explores how Microsoft Visual Studio Async CTP proposes a new way to deal with this problem, introducing asynchronous methods and a new pattern entitled Task-based Asynchronous Pattern (TAP) that will bring the simplicity of the SPM pattern to the asynchronous programming models. Categories and Subject Descriptors D.3.3 [Programming Languages]: Language Constructs and Features abstract data types, polymorphism, control structures. General Terms Design, Standardization, Languages. Keywords SPM, APM, EAP, TAP, Asynchronous, Synchronous, Task, Visual Studio Async CTP. 1. INTRODUCTION For many years software running single threaded code has benefitted from the increase in clock rates of CPUs. No software changes were needed to make it run faster, since the increase of the processing capacity brought by a new CPU was enough to speed up almost any piece of code. In recent years we observed that this tendency is being replaced by increasing the number of CPUs or by adding more cores to a single CPU, reducing in some cases the clock rates of the CPU. In some of these scenarios this change brought a negative impact for single threaded software as the introduction of an extra CPU or core within a CPU with a lower clock speed leads to slower code processing and consequent performance degradation. Furthermore, the software wasn t taking any advantage of the new hardware in terms of processing capacity, the extra CPU or cores weren t used at all. Object oriented languages like C++, Java, Visual Basic.NET and C# provide support for the development of multi-threaded software, but most developers often opt to design and code single threaded code, as multi-threaded development requires higher programming skills and is more difficult to implement, test and debug. Currently the libraries inside the Microsoft.NET Framework use the Asynchronous Programming Model (APM) and the Eventbased Asynchronous Programming (EAP) to expose code that can run in a multi-threaded way, which its consumers can use to produce multi-threaded software using essentially the same patterns. But asynchronous programming using callbacks is difficult and with no language support, callback-based code inverts control, is awkward and is limited in expressivity [1]. As Mads Torgersen mentioned in [2] the problem is that these patterns are very disruptive to program structure, leading to complex and error prone code. As a consequence, developers give preference to a synchronous and simultaneously blocking approach with a negative impact in responsiveness and performance. In [3] Anders Hejlsberg spoke about the future of C# and Visual Basic and introduced the Visual Studio Async CTP [4] which has the goal of bringing asynchronous programming as close to the synchronous paradigm has possible [2]. This isn t new; in fact, a brief look at F# the Microsoft s most recent language shows that the concept brought by the Visual Studio Async CTP [4] is already there since 2007, and in fact C# and Visual Basic are now adopting a similar approach to handle the same problem [1]. This paper does an overview of the new Task-based Asynchronous Pattern (TAP) [5] and summarizes what the Visual Studio Async CTP [4] is. It will also show, how by using the Visual Studio Async CTP [4], most Synchronous Programming Model (SPM) focused developers, can get asynchrony while keeping the clarity and simplicity of the SPM that they are used to.
2. ASYNCHRONOUS PROGRAMMING 2.1 A new Trend Asynchronous programming is getting increasingly relevant in current and future programming languages; in fact it s becoming a norm in responsive and scalable apps [3]. For example, if we look at JavaScript and Silverlight one notices that they only provide asynchronous API s for handling their HTTP requests. Again, observing Microsoft s most recent language F# one can see the importance that asynchronous programming has had in the language design. In fact part of what we get with the Visual Studio Async CTP [4] in terms of asynchronous methods implementation was adopted from the design around asynchronous programming in F#. Asynchronous programming is getting extremely important as we create more applications that need to be connected to remote resources. In such connections, latency and response times increase substantially when compared to connections against local resources. If we look at UI software solutions we notice that the use of asynchronous programming has raised substantially in recent years, Web 2.0 applications or Rich Internet Applications (RIA) are just some examples where we can see asynchronous code on all HTTP server requests. Where server software is concerned, current architectures have increased the communications between services hosted at different machines, so the latency and responsiveness problems described earlier are also a concern in these situations. 2.2 Requirements for a pattern change Although in languages like Visual Basic, C# and others in which one can handle remote operations just like local calls, its usage should be done with care as the success of such execution might depend on several factors which are beyond the developer s control. Normally such calls represent a challenge to the developer, one has to decide whether the call is done synchronously (if there s an option to do it) or asynchronously. In the first case, we're probably faced with a lack of responsiveness and with a thread blocking issue because a remote call is being done, but, as the call is synchronous, the program structure isn't broken and the program code flows accordingly. On the other hand, if the option was to go with the asynchronous call, we no longer have the lack of responsiveness, but now we have greater complexity to deal with the result of the asynchronous call, as the current patterns provided by these languages will disrupt the program structure and make it harder to handle exceptions, just to mention a few of the problems. With the increasing demand for asynchronous programming, it was necessary to bring the simplicity of synchronous programming models to this programming paradigm. Developers need to be able to program their code using a synchronous flow, but at the same time be able to call asynchronous operations explicitly in a lightweight and non-disruptive manner [2]. This is the goal of the Visual Studio Async CTP [2]. 3. TASK-BASED ASYNCHRONOUS PATTERN Stephen Toub fully describes this new pattern in [5] and starts stating that this is a new pattern for asynchrony in the Microsoft.NET Framework. It is based on the Task and Task<TResult> types which are already used to represent arbitrary asynchronous computations. This new pattern is also meant to replace the previous patterns for asynchronous programming whenever the Microsoft.NET Framework is used. 3.1 Defining the TAP In contrast with the APM and the EAP, the TAP requires only one method to begin and complete an asynchronous operation. This is possible because the operation itself must return a Task or Task<TResult> depending on whether a void or a type TResult is expected. The input parameters of these methods should be the same as the synchronous version (if one exists) except for cases where out or ref parameters are specified, as these are not allowed and must be treated differently. Asynchronous methods using this pattern should not block the thread in which they are executed. The method should return the task as fast as possible and with a TaskStatus that has to be greater than Created, which for the task consumer means, the task has already been scheduled so calling Start in the task isn t required (in fact doing so will raise an exception). All exceptions that occur during the execution of an asynchronous method must be assigned to the task that will be returned, and the asynchronous method should not raise exceptions internally except for those that result of bad usage of the operation, like invoking the method with invalid values on its arguments. The implementation of the pattern optionally supports cancelation, and it s up to the consumers to use it. In such cases, overloaded methods should be created and a System.Threading.CancelationToken should be passed in an argument which by convention should be named cancelationtoken. Progress notification is also optionally included in the pattern. To support it, implementers should include an overload with an argument named progress of type IProgress<T>. As per the current version, one implementation of IProgress<T> is provided on a class named EventProgress<T> which implements the interface and also exposes a ProgressChanged event to be raised every time the asynchronous operation reports a progress update. Finally the method name of an asynchronous operation should be suffixed with the Async word (<MethodName>Async) to indicate to his consumers that it represents an asynchronous operation. An exception to this rule exists in the so called Combinators that represent asynchronous operations devoted purely to the creation, manipulation or combination of tasks, and where the method name or the type where he belongs are clear regarding its asynchrony. At the same time, the keyword async in C#, or Async in Visual Basic must prefix the method name to allow the compiler to identify which operations are meant to be modified by the later in order to implement the TAP. 3.2 Implementation of the TAP The Visual Studio Async CTP [4] brings to the C# and Visual Basic compilers the language support to implement the TAP. For this to happen two new keywords were introduced: async and await in C# and Async and Await in Visual Basic. With this two keywords both compilers are now able to translate a code with a synchronous semantic to an asynchronous execution by transforming the C# or Visual Basic source code to a TAP version on the compiled one. This was possible without changing the Microsoft.NET Framework library itself, it only needed to introduce a few more extensions on the assemblies provided by
the Visual Studio Async CTP [4] which in future versions of the library will by fully integrated within the existing types. The work was mostly done at the languages and compilers levels, as the core functionality was already in the library since the introduction of the Task and Task<TResult> types in version 4.0. Beside the support provided directly by the compilers, developers may also implement the TAP. In fact, by doing it, they have greater control on how the asynchronous operations are implemented. Both Compute-bound and I/O-bound asynchronous operations are well-suited to being exposed as TAP implementations [5]. For these, two types are especially suited for representing each kind of computation: types Task and Task<TResult> for Compute-bound operations; and the type TaskCompletionSource<TResult> for I/O-bound operations. By default the first will be scheduled for execution under the context of the ThreadPool either by executing a task with the Task.Run method (or equivalent Task.Factory.StartNew method), or from some Combinator like the ContinueWith method of an instance of a Task or Task<TResult>, the ContinueWhenAll and ContinueWhenAny methods from the TaskFactory. Besides asynchrony these cases will also get in-process parallelism, as a different thread (from the ThreadPool) will be used to effectively execute the computation while the calling thread will continue its work on the same process. For I/O-bound operations this should not be the case, as there s already an OS thread taking care of the I/O operation, there s no need to have a new thread in the process to handle these situations. Threads are expensive, so one should only use them when they re strictly necessary and there s no way to avoid it to reach an equivalent level of performance. In fact, what we want to do in these cases is to free up the calling thread until the I/Obound process is completed, and once it s done, continue the execution of the remaining code on the same thread. This is where TAP with the type TaskCompletionSource<TResult> comes in, as this type exposes a Task property which by default executes on the calling thread and who s life cycle is controlled by the methods SetResult, SetException, SetCanceled and the TrySet* methods. This scenario brings in-process asynchrony without the cost of the extra thread, while at the same time, we get out-process parallelism. 4. TRANSITION BETWEEN PATTERNS Currently there s a lot of code done using the current asynchronous programming paradigms. While we can t just throw way such implementations, we want to be able to get the benefits brought by the TAP and at the same time make this transition in a smooth way. To simplify this transition two patterns were defined. One was defined to transition from APM to TAP and another one to go from EAP to TAP. In fact, patterns to transition from TAP to the other two also exist, but these will not be covered here. 4.1 From APM to TAP Going from APM to APM is done in a simplified way, since there s a pattern which we can follow to do it. The pattern to go from APM to TAP is the following: 1. Create a new method who s name follows the TAP naming convention, which is: <OperationName>Async 2. Make sure the return type is of type Task or Task<TResult> 3. The method parameters should be: a. A type which implements the APM and who s operation is being wrapped to TAP b. The same list of parameters of the <OperationName>Begin method of the APM operation who is being wrapped to TAP 4. The body of the method should throw an ArgumentNullException exception if the APM type that was sent is null 5. The return of the operation is the result of using the static Factory.FromAsync method present in a Task or Task<TResult>, which returns a Task or Task<TResult> The following code from [5] shows an example of such a wrapper where the most relevant points are in bold: static Task<int> ReadAsync( Stream stream, byte[] buffer, int offset, int count) if (stream == null) throw new ArgumentNullException(); return Task<int>.Factory.FromAsync( stream.beginread, stream.endread, buffer, offset, count, null); In this example the Microsoft.NET Stream class which has SPM and APM implementations for the Read operation is being wrapped to implement TAP. For reference let s see the Read signatures of both the SPM (Read) and APM (BeginRead/EndRead) implementations: // Stream Read using the SPM pattern public int Read( byte[] buffer, int offset, int count); // Stream read using the APM pattern (Begin/End) public IAsyncResult BeginRead( byte[] buffer, int offset, int count, AsyncCallback callback, object state); public int EndRead(IAsyncResult asyncresult); Looking at the SPM, APM and TAP patterns we immediately see that the TAP signature is almost the same as the SPM, it differs only slightly in three points: 1. The return type changes from int to Task<int> 2. The name Changes from Read to ReadAsync
3. The first parameter in the TAP implementation Must be a parameter who s type implements the APM operation which is being wrapped If we compare both of the asynchronous implementations APM and TAP, we see that the TAP no longer needs to receive a callback to be invoked when the asynchronous execution ends, neither does it need the IAsyncResult and the <OperationName>End method to effectively retrieve the result of the asynchronous operation. All this is possible due to the fact that the TAP returns a Task or Task<TResult> which encapsulates the whole operation. Using this pattern, all types who expose operations using the APM pattern can be easily converted to the new TAP paradigm, so all the effort that was done to implement asynchronous programming using the APM isn t wasted, no matter if these types are inside the Microsoft.NET library itself or in its consumers. 4.2 From EAP to TAP Converting from EAP to TAP also follows a predefined pattern. A first look at this pattern might seem more complex than the previous one, but besides the fact that it requires a little more lines of code, the pattern itself is also quite simple. In fact, the first situation could also have been wrapped using the pattern showed below: The pattern to go from EAP to TAP is the following: 1. Create a new method who s name follows the TAP naming convention, which is: <OperationName>Async 2. Make sure the return type is of type Task or Task<TResult> 3. The method parameters should be the same list of parameters of the <OperationName>Async method of the EAP operation who is being wrapped to TAP 4. The body of the method should: a. Create an instance of the TaskCompletionSouce<TResult> class who s TResult must match the property Result of the <OperationName>CompletedEventArgs b. Create an instance of the type for which the EAP operation is being wrapped c. Handle the <OperationName>Completed event of instance created in 4b and do one of the following actions: i. Call the TrySetException of the instance created in 4a, passing the Error in the CompletedEventArgs ii. Call the TrySetCenceled of the instance created in 4a iii. Call the TrySetResult of the instance created in 4a, passing the Result in the CompletedEventArgs d. The corresponding previous action is done if: i. The property Error of the CompletedEventArgs isn t null ii. The property Canceled of the CompletedEventArgs is true iii. Otherwise e. Call the <OperationName>Async of the instance created in 4b passing the parameters received in 3 f. Finally return the Task of the TaskCompletionSouce instance created in 4a Here s an example from [5] of such a wrapper. Again the most relevant points are in bold: public Task<string> DownloadStringAsync(Uri url) var tcs = new TaskCompletionSource<string>(); var wc = new WebClient(); wc.downloadstringcompleted += (s, e) => if (e.error!= null) tcs.trysetexception(e.error); else if (e.cancelled) tcs.trysetcanceled(); else tcs.trysetresult(e.result); ; wc.downloadstringasync(url); return tcs.task; The example uses the WebClient class, which has an SPM and EAP implementations of the DownloadString operation. The SPM and EAP signatures are exposed bellow: // WebClient DownloadString using the SPM pattern public string DownloadString(Uri url); // WebClient DownloadString using the EAP pattern public void DownloadStringAsync(Uri url); public event DownloadStringCompletedEventHandler DownloadStringCompleted; public delegate void DownloadStringCompletedEventHandler( DownloadStringCompletedEventArgs e); public class DownloadStringCompletedEventArgs : AsyncCompletedEventArgs public string Result get; public class AsyncCompletedEventArgs : EventArgs public bool Cancelled get; public Exception Error get; // Remaing of the class ommited for simplicity As we can see, the EAP implementation is much more complex than the APM. The EAP model is based on the declaration of a <OperationName>Completed event to signal the completion of the asynchronous operation. As a consequence we need to define delegates for the event handlers and classes for the event arguments of such delegates. All of this makes the creation of the TAP wrapper a little trickier as all of these types are involved. Nevertheless, the EAP to TAP wrapper pattern is always the same so once it s understood it will be as simple to implement as it was for the APM. 5. ASYNCHRONOUS METHODS AND TAP As mentioned earlier the Visual Studio Async CTP [4] brings to C# and Visual Basic two new keywords: async (Async in Visual Basic) and await (Await in Visual Basic); these keywords bring the ability to create asynchronous methods in these languages. 5.1 The async and await keywords Asynchronous methods can be awaited when preceded by the new await keyword. In short, this keyword brings to these languages
the ability to do at the language level what was already possible to achieve at the API level through the usage of callbacks and Task s continuation methods. To be able to await a Task or Task<TResult> on the body of a method, the async keyword is required in the method declaration and it must precede the method name to signal to the compiler that the method is expecting asynchronous calls, which means TAP must be implemented by the compiler. Once the code reaches the await keyword a new task will be created and scheduled to execute the asynchronous method. After that, the method returns immediately to its caller and eventually provides a task to it (cases where the current asynchronous method returns a Task or a Task<TResult>). Once this is done, the thread continues its execution in the line of code that follows the current asynchronous method invocation while the remaining code after the awaited asynchronous operation will be executed once it completes, and most importantly, it will be executed on the context of the asynchronous invocation 1. Such asynchronous methods can return two distinct types: void, if there s no value to be returned; Task<TResult> or Task, otherwise. Typically the first case will be used to deal with event handlers where the approach is fire and forget. For those who return a Task<TResult> or a Task, its usage will mainly be for compositions with other asynchronous methods or Task s previously mentioned Combinators until the Task result is explicitly retrieved or the method is awaited in a void asynchronous method. To demonstrate a simple situation where all these cases can be illustrated let s see an example from [2] where there s a simple method whose purpose is to sum the sizes of the downloaded URI s. public int SumPageSizes( IList<Uri> uris) int total = 0; foreach (var uri in uris) string.format("found 0 bytes...", total); var data = new WebClient().DownloadData(uri); total += data.length; string.format("found 0 bytes total", total); return total; This simple method iterates a list of URI s, and for each one makes a web call to download data from a remote resource. While doing this download the current thread will be blocked while it waits the return from the remote call. This is clearly a situation that will benefit if the execution of such a remote call could be done asynchronously. The WebClient class already has a DownloadDataAsync 2 method which we can use to await the remote call and convert this synchronous method to an asynchronous method. As demonstrated bellow, the changes required to transform this synchronous method in an asynchronous one which uses the TAP are very straight forward. Essentially we need to start by changing the return value of the method from int to Task<int> and preceded the method return type with the new async keyword. Then, we just need to use the TAP version of the DownloadData which is the DownloadDataAsync and await this call. Here s the complete code transformation: public async Task<int> SumPageSizesAsync( IList<Uri> uris) int total = 0; foreach (var uri in uris) string.format("found 0 bytes...", total); var data = await new WebClient().DownloadDataAsync(uri); total += data.length; string.format("found 0 bytes total", total); return total; We can clearly see that the current code version now runs using an asynchronous pattern, while it keeps the control flow of the code and continues to maintain its readability in the same way it was in the synchronous version. This represents a major improvement and will certainly bring asynchronous programming to a level that was not seen before, as almost any developer will now be able to use asynchronous programming calls without the burden brought by the usage of the EAP or APM models. Further details on how this situation has to be implemented without the usage of TAP can be found on [2]. To continue on this example let s see how this new asynchronous version can now be consumed on an event handler from an UI button click event, and do this also in an asynchronous way using the TAP. // Asynchronous void method using TAP private async void sumbutton_click( RoutedEventArgs e) sumbutton.isenabled = false; await SumPageSizesAsync(GetUrls())); sumbutton.isenabled = true; For further analysis the synchronous version of a similar code is also presented, and as we will see the differences in execution will be bigger than the similarities of the code. 1 If context prevalence isn t required, the cost of context switching can be avoided. 2 In fact the method is called DownloadDataTaskAsync and is defined in the Visual Studio Async CTP [4] as an extension method for the WebClient, where it was implemented as a wrapper for TAP around the EAP implementation.
// Synchronous version provided for analysis private void sumbutton_click( RoutedEventArgs e) sumbutton.isenabled = false; SumPageSizes(GetUrls())); // Blocks the thread sumbutton.isenabled = true; If we start the analysis on the synchronous version, we notice that we can t call the asynchronous version of the SumPageSizes, so we have to use a synchronous version of the operation, which leads to the problem of the thread being blocked until the operation ends. As a consequence the expected behavior of disabling the button before the call and enabling it afterwards will never be noticed as the thread is blocked in the operation call. On the asynchronous method version, all these problems go away. In the first place, as the button handler is an asynchronous method we are allowed to await operations in it, so we can await the asynchronous version of the DownloadData using the DownloadDataAsync method. The expected behavior of disabling the button while we are downloading data, will now work as expected, as the thread will be freed on the await and the UI thread will be able to continue to process messages. Finally, once the download data completes, code execution will be resumed on the sumbutton.isenabled = true statement, and it will run on the UI context as expected. 5.2 Exception handling In terms of exception handling, TAP greatly simplifies the work that needs to be done. If an asynchronous method leaves an exception unhandled, it will be marshaled to the returning Task or Task<TResult> and will put the Task in a Faulted state. This rule is only broken when the exception is of type OperationCanceledException, raised due a cancelation request that has been processed by a cancelation token, in which case the Task will be ended in the Canceled state. So, handling exceptions for an asynchronous method is similar to handling exceptions for a synchronous one. Let s see how we can check for exceptions in our DownloadDataAsync method: private async void sumbutton_click( RoutedEventArgs e) sumbutton.isenabled = false; try await SumPageSizesAsync(GetUrls())); catch (Exception ex) // Handle the exception sumbutton.isenabled = true; As we can see, handling exceptions with the TAP it s as simple and natural as it can be. It s just the same as when we do synchronous code. All the hard work is now resolved by the language support along with the C# and Visual Basic compilers which together are able to bring simplicity for the TAP consumers. An approach to the TAP implementation details regarding the syntactic expansion that is done by the C# compiler can be found in [6]. 6. CONCLUSIONS APM and EAP patterns are clearly inappropriate for the current challenges, e.g., where the needs for asynchrony and parallelism are everywhere. A new and more simplified way of dealing with these requirements was needed to keep developers focused in the business logic instead dealing with technology artifacts. The Visual Studio Async CTP [4] as an early preview of what we can expect for the next version of C# and Visual Basic is the answer provided by Microsoft to accomplish this, and the vision behind it seems to be perfectly aligned with the current needs for asynchrony and parallelism as they appear in every day s developer lives. This paper briefly discussed what the Visual Studio Async CTP [4] is and which are the goals it tries to reach. A lot was left uncovered, for instance the built-in task Combinators: Run, WhenAll, WhenAny and Yield; the construction of Task-based Combinators and Task-based Data Structures; both have a key role on building larger patterns [5]. Many details were also absent from this article as they can be found in [2], [5] and [6]; the purpose of the article was mainly to expose the technology in conference literature. TPL Dataflow also introduced by the Visual Studio Async CTP [4] was not discussed in this paper and is meant to be covered in another article along with the benefits that it brings to the development of concurrent applications. Finally, asynchrony is not the same as parallelism, but TAP not only simplifies asynchrony, it also provides a vehicle for parallelism in a better and simplified way. Once developers start to adhere to this new pattern they will see how fast and simple it can be to implement operations that can easily be consumed in asynchronous and parallel environments. In fact, current operations that already expose tasks in their return values are possible candidates for this, and the next step would be the usage and implementation of asynchronous methods around those tasks. 7. REFERENCES [1] Syme, Don, Petricek, Tomas, and Lomov, Dmitry. The F# Asynchronous Programming Model. In Practical Aspects of Declarative Languages (PADL'11) (Austin, Texas, USA 2011). [2] Torgersen, Mads. Asynchrounous Programming in C# and Visual Basic. Microsoft. 2010. Visual Studio Async CTP Documentation. [3] Hejlsberg, Anders. PDC10 - The Future of C# and Visual Basic. Microsoft. 2010. http://player.microsoftpdc.com/session/1b127a7d-300e-4385- af8e-ac747fee677a. [4] MICROSOFT. Visual Studio Async CTP. 2010. http://msdn.microsoft.com/en-us/vstudio/gg316360. [5] Toub, Stephen. The Task-based Asynchronous Pattern. Microsoft. 2010. Visual Studio Async CTP Documentation. [6] MICROSOFT. Asynchronous Functions in C#. 2010. Visual Studio Async CTP Documentation.