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.
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.”
I think the old way of writing delagates and BeginInvoke with SyncLocks on Queue objects is easier than this junk. Why does Microsoft have to keep shifting the goal posts!!! just implement async once.. and do some decent documentation on how to use it in the real world.. instead you just add more junk library code to the .net framework, still with lack of examples and documentation, and yet you still over complicate it with new features like this, instead of demostration with real world async documentation... you haven't acheived anything with this new async compiler stuff.. I have spent 3 years writing async code for .net framework... and yes I still see better ways of queue and dequeue objects being passed around threads every day... and using synclocks etc.. and yet I have never seen any of this real code in Microsoft documentation on "this is how to do async programming, real world style". Microsoft you need to stop the developers floundering how to use this async stuff and help us come up with cool ways to use the orginal stuff you built. now you have just given the developers some more methods to flounder with... but you still haven't made any headway.
The next question would be: is the VS vNext built upon async? I mean how VS vNext utilizes async internally (to improve its performance).
More MSDN Magazine Blog entries >
Browse All MSDN Magazines
Subscribe to MSDN Flash newsletter
Receive the MSDN Flash e-mail newsletter every other week, with news and information personalized to your interests and areas of focus.