.NET 5.0 async & await keywords

Associate
Joined
6 Jun 2004
Posts
2,389
Location
London
http://player.microsoftpdc.com/Session/1b127a7d-300e-4385-af8e-ac747fee677a

What does everyone think of it?

I can't wait to see this feature. I've spent so long cursing the need to write callbacks and loved the llamda feature when it arrived for the purposes of writing inline anonymous methods to call backs. We had an inhouse implementation of the task framework which we plan to replace with the native Task classes from .NET 4.0 when we get around to upgrading to VS 2010 and I already want to upgrade to .NET 5.0 :)
 
Any non-silverlight links available? :p

edit: Just read through some of the above posted blog.

Isn't this just syntactic sugar (and, at first look, dangerous/risky) for managing threads? I don't like the look of this as a method much:
Code:
static async Task GoBangAsync() 
{ 
    throw new Exception("Bang!"); 
}
That should be (imo):
Code:
static Task GoBangAsync()
{
  return new Task(() => throw new Exception("Bang!"));
}
and is entirely do-able in C#3.5, let alone 4:
Code:
static Action GoBangAsync()
{
  return () => throw new Exception("Bang!");
}
where you just use .invoke() method call instead of the keyword "await"?

What I am missing about this new feature? :)
 
Last edited:
It appears to just be some syntactic sugar the wraps around the Task Parallel Library (TPL) that they introduced in .NET 4.
 
Hmm.. not liking their usual marketing strategy of "lets make the stuff we don't like as horrible as possible whilst leaving out a few details in the new stuff to make it look extra fluffy". Gotos? Seriously?

Anyway. It sounds nice, but I just don't like the idea of implicit returns I guess. What if I need that method to throw that exception at the time it is called, and not within the context of the task. Perhaps I'm not understanding it. Testability sounds like a complete nightmare.
 
I think this has highlighted, reading the blogs of various .net devs, is how poorly understood threading is.

Is that really surprising given that 90% of the .NET ecosystem seems to be comprised of ASP.NET devs who always "let IIS take care of that for me" ?

It is actually so bad with some ASP.NET devs that they don't actually realise that .NET is used for non-web projects as well.
 
Any non-silverlight links available? :p

edit: Just read through some of the above posted blog.

Isn't this just syntactic sugar (and, at first look, dangerous/risky) for managing threads?

What I am missing about this new feature? :)

Yes it is just syntactic sugar - just as foreach loop is syntactical sugar for a for loop, but it completely changes how your asynchronous code looks.

I love tasks - they encapsulate an asynchronous actions (not just background thread work aka invoke) so network, I/O reads etc all can be wrapped in these Tasks. With Tasks come great abilities to ContinueWith other delegates once they complete, combining tasks to trigger an action when they all complete and other such goodies. MS have now layered some lovely language keywords on top of this to rid yourself of messy callback methods, and even anonymous methods meaning you can write your code synchronously and allow it to sort out it's asynchronous calls behind the scenes.

This is great because if you have ever used callback methods, you will have realised that you often need class variables to keep state between the "request" and the callback firing with the "reply". This litters your classes with stateful variables and generally detracts from your design. Anonymous methods (llamda delegates etc) are better since you can use in-scope variables when you define the method so all your request/reply state stays local inside the "request" method (along with the reply logic) but exceptions and other cases are still not handled nicely - as well as your code looking pretty ugly at times, particularly if you have nested, sequential Tasks. These new keywords allow any amount of nesting and exception handling just as you would code them synchronously.

As with most high level language features, it's important that you understand what is going on behind the scenes first but I think this will be a great help for me. We place critical importance on our applications not freezing up during network/database/IO accesses, and also we don't like too many threads (due to locking) so balancing those is difficult - until this came along.
 
Last edited:
Back
Top Bottom