Asynchronous Programming Now and in the Future

Hello everyone!

I recently spoke at an MSDN geekSpeak on Asynchronous Programming techniques and how they have evolved over time.  I wanted to give just the highlights of the different techniques and post the code.  So here is a list of the different techniques I showed around making WCF calls in WPF and Silverlight asynchronously and some pros and cons about them!

  1. Event based – This technique was probably one of the first ways to write code that can be notified when an asynchronous process is complete.  This technique helped in that it was a solution to the problem, but the code can be very disjointed and hard to read.  Sometimes you only ever want to be notified through one chain of operations but with eventing it reads like it could happen multiple times
  2. Lambda Callbacks – Lambdas definitely helped to make the code more readable and took away the need for cleaner management of events.  We still have certain ways we have to execute our operations and are never guaranteed that code will fire in order so we have to work around it.  However this was a very big step towards making asynchronous coding more manageable and readable.
  3. WorkerQueue – A friend and co-worker of mine Nathan Allen wrote a tool that takes the idea of lambdas and really organizes the underlying processes to make it even easier to manage code.  With the WorkerQueue you actually write synchronous code but you choose which lines you want to execute on a background thread versus lines you want to push to the ui thread and wait for them.  This helps us to write synchronous code while still yielding the ui thread so we don’t lock up on longer running processes.  You can get the code for this tool on his blog here.
  4. Visual Studio Async CTP (await/async) – With the new Visual Studio Async CTP Microsoft has really “straightened” out asynchronous programming by abstracting the complexity with threading and the like.  With this new concept you truly write synchronous code without hardly any extra effort.  In fact when you write code like this you can almost completely write in the way that synchronous code is written with a few extra keywords.  Basically this implements some compiler sugar that for an async/await method creates a little mini state-machine.  It will execute the lines until it hits an await then executes that on a Task, when the Task is completed it updates the state and executes the next step of the state machine.  This is definitely my favorite technique next to using the WorkerQueue and I am eagerly awaiting the release of this extension.

I have posted the code samples here.  You will probably need to install the Visual Studio Async CTP and you can get it and more information here.  I don’t believe that this changes any core .net, just the compiler and visual studio.

I will be speaking on this topic at various events and will post each event I am speaking at on my blog.  If you are in the area and would like to learn more about asynchronous programming then please come!

I hope you enjoy this and happy coding!

  1. #1 by Justin James on February 10, 2011 - 12:53 am

    Jason -

    Thanks again for the talk tonight! I’m writing an article on this topic now, and I was going through the code samples and I saw that Async CTP actually has a class for reporting progress, though I would pass that on since someone asked about it tonight.


  2. #2 by Joe on February 19, 2011 - 11:09 am

    Hi Jason,

    Thank you for the presentation; I learned something new; specifically the WorkerQueue method and all for simplifying how to sequence order-important calls for asynchronous operations.

    I actually submitted a query to the Silverlight forum regarding sucb processes and how they could work with user-interaction where the service call requires intervention.

    I was surprised that you did not mention the ‘iterator’ method which is apparently used by the Caliburn framework and in general, allows asynchronous processes on the client side to be executed ‘serially’ and in a very (almost sequentially) readable manner.

    I am glad that you covered the ‘Dispatcher’ for updating the UI from different threads; however, I think you should have mentioned that those using DataBinding techniques (such as INotifyPropertyChanged) do not needs to worry about dispatching the calls to the UI thread. (Unless there is something of which I am unaware.)

    BTW, I was the one who asked you about the ‘Custom Enumerator’ method at CodeCamp, as many others do, I was looking for some “experienced” methodology in simplifying the design. I wasn’t trying to heckle, I promise.

    Yours was one of the best I had attended this year, thank you very much for the presentation.

  3. #3 by Jason Rainwater on February 24, 2011 - 1:48 pm

    Hi Joe,

    Thanks for coming I am very glad you enjoyed it :)

    Yeah i should really be showing using the reactive framework as another means of asynchronous programming because it too uses the iterator pattern. I am hoping to build something like that into my presentation for future events.

    On the databinding and dispatching item you mentioned. A property on a visual is databound to an object that lives on the ui thread. So therefore if move that object to a background thread then change a property on it the databinding will not fire because it is looking for changes on the object on its own thread, so we use the dispatcher to push the results back up to the ui thread so that when we change the property the binding will properly update.

    Once again i am glad you came, i love doing code camps and am looking forward to many more.

  4. #4 by Manpreet on April 24, 2011 - 10:55 pm

    Hi ,
    I am not sure if I can use this technique in WP7.

  5. #5 by Jason Rainwater on April 27, 2011 - 3:11 pm

    Before you could not, but since the CTP refresh for VS 2010 SP1 it now includes WP7 support

Comments are closed.