New Early adopter or innovator? InfoQ has been working on some new features for you. Learn more

Why Microsoft Believes that VB and C# Need an Asynchronous Syntax

| by Jonathan Allen on Jan 04, 2011. Estimated reading time: 3 minutes |

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.


Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Less code by .Net developer

Well, I took a look at somasegar blog and it looks like less lines of code and also more comprehensible code. I hope We can come rapidly into this specially for silverlight where most of code looks like the "old way" sample.

Re: Less code by Floyd Marinescu

Hi .Net Developer, would you be so kind as to edit your name under 'preferences' to your real name? We have a real name policy on InfoQ to encourage serious and constructive discussions.


Floyd Marinescu
co-founder and Chief Editor

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

2 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date with curated articles from top InfoQ editors

"You dont know what you dont know" change that by browsing what our editors pick for you.