October 2011

Volume 26 Number 10

Editor's Note - Thinkin' About Async

By Michael Desmond | October 2011

This month MSDN Magazine explores the powerful new asynchronous programming features coming to the next versions of C#, Visual Basic and the Microsoft .NET Framework. Available today via the Visual Studio Async CTP, the new functionality helps resolve one of the biggest emerging headaches in the age of multicore systems and cloud computing: the penalties incurred when threads are blocked waiting for things like data to return from a remote server or a computation on another thread to complete.

I spoke with Mads Torgersen, author of one of this month’s features on asynchronous programming and a principal program manager on the C# and Visual Basic Language team at Microsoft. He notes that almost every application is becoming connected and that latency is emerging as “a central problem to code around.” So why didn’t we see async support in the .NET Framework 4?

“At the point where the feature set was locked down for that release, we didn’t have a serious grasp on what such a language feature should look like,” says Torgersen. “However, F# shipped at the same time with an asynchronous language feature that ended up inspiring us a lot. By the time we shipped C# 4 and Visual Basic 10, we were seeing mounting evidence that asynchrony should be next in line, and that it was a problem that really needed to be solved at the language level.”

Torgersen describes the core implementation approach as quite simple. The solution was to “pause and resume” the execution of code in flight. Rather than chop up generated code into separate bits, the team used a technique to “parachute in” to the proper spot in the user’s code. The approach provides the benefit of retaining the structure of the original source code—and the results are hard to argue with.

“We’ve had a surprisingly small bug tail of inconsistencies,” Torgersen says.

Async Evolution

The new asynchronous programming features in C# and Visual Basic mark the latest in a series of important evolutionary steps for Microsoft’s flagship managed programming languages. Over the past few years, the languages have taken on aspects of functional and dynamic programming, and most recently asynchronous programming. As Lisa Feigenbaum, program manager in the Visual Studio group at Microsoft, explains, the effort was made to incorporate these capabilities in ways that “best fit the style of each language.”

“For example, dynamic language interop was added to Visual Basic by taking advantage of the late binding constructs that were already part of the language. Furthermore, in C# we added a static type, called dynamic,” Feigenbaum says. “Speaking of functional programming, when adding lambdas to Visual Basic, we used the familiar keyword syntax with Sub/End Sub and Function/End Function. However, for C#, which is less verbose, we used symbols to design the syntax with ‘=>’. These designs help each language preserve its original character and remain familiar to developers as it grows.”

Adding significant new functionality to a programming language is never a trivial matter. Feigenbaum describes language design as a “very conservative process,” emphasizing that features are not added until they’re exactly right. In the case of async, the new functionality is built on foundations introduced with the last version of the .NET Framework.

“For example, the Visual Studio vNext async designs build upon the Task type that was added to the .NET Framework in .NET 4,” says Feigenbaum. “Using that foundation, as well as additional Framework support that’s being added in the next version, we were ultimately able to design a very elegant language syntax that we were happy with for async in Visual Studio vNext.”

Today, developers can work with the Async CTP to become familiar with the new resources coming to C# and Visual Basic. In the meantime, Torgersen says developers can do one thing to best prepare for the age of async: become Task-based.

“Even on .NET 4, the Task types are a much better currency for asynchronous activity than the older patterns we have. You still need to be callback-based because you don’t have the language support, but in a more elegant way. And having all your signatures follow the new Task-based pattern will prepare you beautifully for the day when you can consume those with just a simple ‘await’ expression.”