Cbachellam
Tuesday, March 8, 2016
Atlanta, GA.
Setting the stage:
Today we are satisfying our craving towards sugary syntax for complex structures in asynchrony in C#. Though we have dealt with asynchrony in JavaScript in the previous blog post, this blog post ignites questions like, why do we need async / await keywords in C#, the genesis or under the hood internals of asynchrony, what are its marked strengths and advantages, also dispel the myth and fallacious thinking etc. These are questions which have been nagging me from the moment I was exposed to asynchrony in C# and hopefully will alleviate pain.
Asynchrony in C#:
Asynchrony has been there from get go(gecko). There is nothing unique about it except syntactical sugars. In C# any long running activity like reading a large file I/O operation or waiting for high latency network I/O operation can lead to blocking the UI thread and the GUI hangs for the response. This lead to the genesis of asynchronous processing; non-UI blocking activity, which is the prime driver of all this invention. We previously had asynchronous operations in Silverlight API’s, like in a real world instance, where the user interacted with the autocomplete suggestion text box which hung up for every alphabet the user typed in, trying to serially process the input and waiting for the response. To get around this, class: HTTPWebRequest’s special asynchronous method BeginGetResponse takes in a callback as a parameter. The callback is fired on successful completion of receiving the response. In other words, the UI thread continues to perform other activity and tangentially fires off the long-running network I/O operation and on completion, calls the callback which updates the UI with the response data. This way the non-blocking UI thread is achieved. Please note that I would like to dispel the myth- this doesn’t improve the performance but on the other hand, improves the responsive nature of the GUI without blocking the user interaction.
Now how can we connect the dots with async/await keywords in modern C#? Let’s say if we have a chain of asynchronous instructions which gets fired on completion of one after another. The code gets unwieldy, complex and convoluted. Imagine jumping from callbacks to callbacks, which is unreadable and soon becomes a coding nightmare. To get around this, C# came up with a sugary syntax, that kind of eliminated the chafe and logic callback hops that one has to go through in understanding and reading the async code.
Does async / await spawn a thread?
As described in the above discussion, any activity that doesn’t stop or block the main UI thread and fired off tangentially can be boldly claimed as asynchronous. But the question is does this tangential firing, spawn a thread. No, it doesn’t. Async code doesn’t create a thread. But on the other hand, it uses Thread Pool.
vis-à-vis JavaScript
This I see a major difference between JavaScript and C# asynchrony. JavaScript is more along the lines of a single thread getting chopped for multiple asynchronous operations. On the other hand, C# async is reusing the threads from the thread pool. Both are ultimately syntactic sugars and improve the responsiveness of the UI.
Design Nutcracker 