Microsoft Launches Visual Studio Async CTP
Anders Hejlsberg described the roadmap for C# and Visual Basic at PDC 2010. The main goal of the next versions of both C# and Visual Basic is to make asynchronous programming as simple as synchronous programming.
Hejlsberg's vision proved to be an exciting introduction to the new syntax and APIs for asynchronous development that are available in the new Visual Studio Async CTP.
Asynchronous programming is very important to provide a responsive UI. In fact, whenever you create a new Task in .NET Framework 4, this task represents an asynchronous operation. Asynchronous programming is becoming the norm in responsive and scalable applications. The introduction of TPL (short for Task Parallel Library) simplified the creation of code that runs with an asynchronous execution because you can work with tasks instead of working with managed threads. However, you have to understand delegates, callbacks, closures, the different techniques to pass data to the delegates and you must add many lines of code to coordinate all the asynchronous calls. Generating a responsive UI requires more complex code than simpler synchronous code.
Anders mentioned the fact that we are developing increasingly connected applications. Therefore, there are more UI responsiveness problems, further scalability issues and also an additional overall latency. Asynchronous programming is necessary to unblock the UI thread and to provide users with responsive applications.
However, there is another problem for .NET developers. If you want to develop Silverlight 4 applications, you cannot take advantage and you have to use the old .NET threading model to take make asynchronous calls. I explained this problem in "Silverlight 4 RC Stays With the Old .NET Threads; F# Helps."
Asynchronous programming is very important to allow Silverlight to interact with data and services. For example, the new SharePoint Silverlight Client Object Model allows Silverlight to interact with elements in a SharePoint 2010 Site. This Client Object Model exposes asynchronous operations and requires the developer to write code that runs in different threads. The asynchronous execution is complex because it involves code running in different threads and you cannot take advantage of TPL. My book "Microsoft Silverlight 4 and SharePoint 2010 Integration" dedicated many interaction diagrams to explain the execution of simple asynchronous calls to the Client Object Model. A single request to execute a query on the SharePoint 2010 server and update the UI requires you to pay attention to complex multi-threading issues.
You can use Visual Studio Async CTP in a Silverlight 4 application. Once you installed the Visual Studio Async CTP, you must add a reference to AsyncCtpLibrary_Silverlight.dll in your Silverlight 4 project. This means that you will be able to simplify your asynchronous code in a Silverlight application by using the same code that you use in a WPF or Windows Forms application. You can start working with the new async and await keywords in Silverlight 4 but you will have to wait for the next Silverlight version to access Task<T>. .NET Framework will use Task<T> for all asynchrony; therefore, you will have access to Task<T> in a future Silverlight version. It makes a lot of sense to use Task<T> to represent any asynchronous operation and to make it available to Silverlight.
Asynchronous programming is easier with Task<T>, its status information and its continuations. The problem is when you get used to Task<T> and you have to work in Silverlight, because you have to forget about Task<T>. The goal is to make asynchronous programming just like synchronous programming. Thus, Microsoft introduced TAP (short for "Task-based Asynchronous Pattern"). This new pattern is closely related to the TPL and allows you to follow simple rules to create methods that are compatible with the two new keywords added to simplify asynchronous programming:
- async: This modifier marks a method or a lambda expression as asynchronous. When you are going to make asynchronous calls by using the await keyword, you need to add the async keyword to the method's signature.
- await: This operator yields control until a task completes. By using this modifier, you don't have to create callback functions anymore. The compiler does the necessary work to transform your code into an asynchronous call and also handles the necessary conversion to return T, instead of Task<T>. As a result, the code is really simpler to write and easier to understand.
Many of the ideas that were part of the Parallel Extensions Extras project are included in Visual Studio Async CTP, as I explained in ".NET 4 Parallel Extensions Also Have Powerful Extras." (http://www.drdobbs.com/go-parallel/blog/archives/2010/05/net_4_parallel.html) When you start using tasks to schedule, execute and control concurrent code, it is easy to realize that you can simplify the code required to handle multiple asynchronous operations. In fact, my advanced book on Parallel Extensions "Professional Parallel Programming with C#: Master Parallel Extensions with .NET 4" dedicates many chapters to explain the advantages of using tasks to perform diverse kinds of asynchronous operations. I even had time to include some information about Visual Studio Async CTP. Luckily, you will be able to take advantage of your knowledge in working with tasks when using Visual Studio Async CTP. If you don't know about task-based programming and you want to create responsive applications, you should start learning parallel extensions right now because they will be even more important in future .NET and Silverlight versions.
Visual Studio Async CTP is interesting because it simplifies the creation of asynchronous code and it defines a modern pattern. Asynchronous code is also very important to take advantage of multicore power. I'll dive deeper on TAP and this CTP in subsequent posts. You can download the Visual Studio Async CTP (short for "Community Technology Preview") at http://msdn.com/vstudio/async and check the new features by yourself. Stay tuned!