All about Async/Await, System.Threading.Tasks, System.Collections.Concurrent, System.Linq, and more…
Thanks to everyone who attended my "The Zen of Async" presentation on Thursday at the MVP Summit. As I've had several requests, here are the slides and code for the talk.
Hi Stephen, I have been following your blogs and learning really cool stuff. Can you please provide the video of this talk if available?
Unfortunately, there's no video available of this session. I'm glad you enjoy the blog, though.
Hi Stephen, thanks for the great presentation!!
Now I have a question about the code snippet on the 13th page of the slide.
It show that the overridden method Stream.ReadAsync calls Stream.Read synchronously, and then wrap the result in a task object and return it.
Does that mean that I can await on ReadAsync and it will not block the UI if I await it on UI thread?
Since I tried similar stuff but I got the UI blocked until the reading is finished, so I am confused about that.
I'm glad you enjoyed the presentation.
The key in this example is that we're calling Read on a MemoryStream, where Read simply copies some in-memory data from one buffer to another. You can await ReadAsync on the UI thread and it will not block the UI thread.
When we use Task or await/async pattern of C# 5.0, are we internally using I/O thread? Basically I wanted to know that if I am calling web service operation 100 times in for loop each iteration executing on a separate Task, will it create 100 threads internally or will it use I/O threads and only couple of threads will do the job?
For example if I use PowerThreading-Library provided by Jeffrey Richter, It has component called AsyncEnumerator and it uses I/O threads internally if required. I am sure you must know about it.
Thanks for your time Stephen.
So in this sample we can call Read synchronously in ReadAsync and we do not afraid the impact to UI is because the cost of Read is relatively small, not because we use the await on ReadAsync, is that correct?
void async OnButtonClick
HttpClient Client = new HttpClient();
var Result = await Client.GetHttpDataAsync(); // block UI for several seconds?
public Task<ResponseMessage> GetHttpDataAsync()
var Result = GetHttpData(URL); // spends several seconds
Upsilon- Any XxAsync method should return to the caller very quickly and do very little work. In some cases, the amount of work the asynchronous operation would do is so small that it makes more sense to just have it complete synchronously. That was the case with MemoryStream.ReadAsync. That's not the case with your GetHttpDataAsync method... spending several seconds is way too long for an XxAsync method to synchronously return.
Sandeep. it depends primarily on the operations you await. Calling a function marked as async doesn't schedule any work: that function starts executing synchronously on the current thread. When the function then encounters an await on something that's not yet completed, it hooks up a callback that will be invoked by the awaited thing when the awaited thing completes. The implementation of that thing and what threads it uses (if any) is entirely up to it.
Thanks a lot Stephen. It really helped. I can't believe Stephen is answering my questions!!!!
Glad to help.
Stephen, are you planning to write a book on fundamentals of Task and any abstractions on that like Dataflow? I can await on that :)
I'm not currently planning on writing a book, but you might be interested in these that I previously worked on:
Thanks Stephen. This is something I was looking for.
Great persentation! Loved it.
Just a question which is in my mind from longtime and looking for answer.
Any database operation called from .net web application for example- Microsoft.Practices.EnterpriseLibrary.Data.Database.ExecuteNonQuery()
Will it be called on IO thread or worker role thread will call it and go in suspended mode to await?
@Rajeev V: thanks, glad you enjoyed the presentation. As for your question, it entirely depends on the implementation of the operation. If you call a synchronous method, you're going to block the current thread until it returns, and then the implementation could use zero or more additional threads based on how the dev implemented it. If you call an asynchronously, it could similarly use zero or more additional threads in its implementation; it could be that it's implemented using async I/O, which means you'll likely only be using some additional threading resource when you have work to be done in processing the request or response, or it could be implemented to just queue a work item to some other thread that calls the synchronous implementation.