All about Async/Await, System.Threading.Tasks, System.Collections.Concurrent, System.Linq, and more… language and library features.
Here they are. If you read them all, we recommend you read them in the following order:
Enjoy!
Very good news!
Thx
Bruno
After some brief initial flashing where code is hidden during loading, Eric's article reads out like this:
Imagine what the world would be like if people worked the same way as computer programs:
1. void
2. }
Either Eric is very solipsistic and maybe in need of a hug (life's a void and then you end curly), or there is a formatting issue. This happens in Safari and Firefox.
Thanks, Jesper. The MSDN Magazine folks are now aware of the issue and are looking into it.
Hi Stephen,
Wondering if you/the-team is coming up with a TPL black bible book anytime soon covering 4.5 enhancements? I'd love to read a book written by you especially.
Thanks,
Rohit
Hi Rohit-
Thanks for the feedback. I'm not currently working on a book, but it's nice to know there's interest. At the very least, we'll continue to blog actively.
I don't understand why none of those articles and none of the parallel programming blog posts have Visual Basic code. :(
I know that we can use it also in VB and I don't have problems reading C#, but I would love to see Visual Basic examples in it.
But nice articles on MSDN Magazine and really nice work from the pfxteam ;)
how r u?
its really amazing technology..but as its not open source people are not aware of its power..
hi stephen
this is the first time i m leaving comment, API's are better or namespaces and classes are better. and how can i be a programmer, as i am in another job. and have no degree in programming but some touch with VC and VC#. how can i be productive?
ms khan, you're asking how to learn to program? Do you have a sense for what kind of apps you want to build? You might start at msdn.com, following through to whichever platforms you want to target, and reading through the various tutorials available there, watching videos, etc.
I am wondering why there is so much overhead done with async programming. If you take a look at web programming (JavaScript) with jQuery and its AJAX calling mechanism, which is also asynchronous per definitionem, there are simply two delegate callback functions specified as parameters: one for successful execution, and one that is called if any error occurs.
That's a fairly simple concept, easy to understand and easy to use. Why not implement a similar concept in C#? Then you don't need await since you have the 2 callback delegates instead.
Matt-
I assume when you say "overhead" that you're referring to conceptual overhead?
We have that basic model in Task as well... the ContinueWith method takes a delegate which will be invoked when the operation completes. The delegate is handed the completed task to process however you like, accessing its Result, its Exception, etc. There are also more involved overloads that allow you to, for example, specify that the continuation should only run for certain completion states, e.g. only if the task faulted, or only if it ran to completion successfully, etc.
But await goes beyond that. It in effect layers on top of ContinueWith to enable you to use all of the control flow constructs in the language, allowing the compiler to do all of the heavy transformations rather than forcing you to do so. For a single asynchronous operation, the simple model you describe is fine. But as the code gets more involved (e.g. a loop around an asynchronous operation), the code you have to write with such a model gets voluminous and complex... that's where await comes in.
If you haven't already, I'd suggest reading Eric's article at msdn.microsoft.com/.../hh456401.aspx, as well as exploring all of the informative material at.
I want to continue to read it.