Why Microsoft Believes that VB and C# Need an Asynchronous Syntax
For the last few years multi-threaded programming has been an increasingly hot topic. While the need for highly responsive user interfaces has been with us for decades, the tools we have for fulfilling that need haven’t changed much. Updates to the user interface are still limited to a single thread for most frameworks including all those available to .NET programmers. Meanwhile hardware manufacturers have been turning to multiple cores in lieu of increasing faster CPUs.
C# and VB started with very simplistic concurrency support via the lock/SyncLock keyword for monitors and delegates for use with asynchronous libraries. For the next few versions we didn’t see any meaningful progress in the area, attentions instead being paid to other areas. With .NET 4.0 that all changed. Three new libraries were introduced: Task Parallel Library (TPL), Parallel LINQ, and Coordination Data Structures (CDS). These libraries built upon the syntax enhancements such as lambdas, closures, and LINQ to greatly simply multi-threaded development. But what they didn’t do is abstract away the fact that one is using the libraries. Parallel LINQ seems to have worked out well, but asynchronous calls with TPL is still visually messy and somewhat error prone.
A big part of the problem with today’s asynchronous patterns is that they don’t compose well. Each asynchronous operation is chained to the next using callbacks. But callbacks not composable; each step is an independent function that cannot be grouped into common coding structures like loops, using, or try-catch blocks.
As a result, most developers don’t actually use the asynchronous patterns. Instead they turn to concurrent multi-threading, where in they rely on background threads and manual synchronization. But this has its problems as well. By wasting threads on blocking I/O you lose the performance and scalability benefits of operating system features like I/O completion ports, not to mention the memory overhead of spinning up a lot of threads. Alternately you can use a single thread and a loop, which means each I/O operation cannot start until the previous one finishes.
That said, we’ve been writing code this way for a long time and under most circumstances it works. Computers generally have more than enough speed and memory to handle sloppy use of threads and marshaling the data back to the UI thread isn’t that hard. So what changed?
Well three things.
First up are the foundation projects. The Async CTP wasn’t invented in a vacuum; it is based heavily on research and production projects that came before it. These include the asynchronous language Axum, the Task Parallel Library (TPL), Reactive Extensions (Rx), and F#’s asynchronous workflows. With all this work already done, async syntax inside VB/C# is the next logical step.
The second is the people involved. Instead of using random grad students like many research projects, Somasegar formed a team of five highly talented PMs were tasked to build a syntax that could demonstrate that asynchronous programming could be as easy as synchronous programming. These developers, Avner Aharoni, Mads Torgersen, Stephen Toub, Alex Turner, and Lucian Wischik, are well known for their work on the .NET. Without their skill and dedication this CTP wouldn’t have happened.
Finally there is Silverlight. Besides being an alternative to Flash, Silverlight is vital to Microsoft’s mobile strategy. Unless you are making a game, you cannot write an application on Windows Phone 7 without using Sivlerlight. And Sivlerlight does not support synchronous I/O operations. As anyone who has tried to port WPF code to Silverlight knows, they simply don’t exist. This you have no choice but to use asynchronous patterns. Lucian demonstrates how complex this really is in his “A technical introduction to the Async CTP”.
Of course this necessarily means C# and VB should be altered to support the async syntax. If this actually does find its way into C# 5/VB 11, there will be little or no chance to remove it if it’s found that the semantics are wrong. And it has to come at the expense of other features ranging from “compiler-as-a-service” to the countless minor annoyances that always seem to just barely miss the cut.