Does await completely block the thread?

Question

When we use await in the code, generally the awaiters capture the context and use that as callback when the awaited task completed successfully. But, since await is generally a No-Op (No Operation), does it make the underlying thread not being reusable until execution of the awaited task completes?

For Example:

public async Task MethodAAsync()
{
    // Execute some logic
    var test = await MethodB();
    // Execute remaining logic
}

Here, since I need the result back to proceed further, I need to await on that. But, since we are awaiting, does it block the underlying thread resulting thread not being used to execute any tasks?

Ballocks

My understanding is Task will continue as No.Op but multiple tasks can be executed in the underlying thread and hence it is not blocked. – Ballocks

If it did block, what good would the feature be? It would be equivalent to calling .Result. – Response

Answer 1

But, since await is generally a No-Op (No Operation), does it make the underlying thread not being reusable until execution of awaited task completes?

I'm not sure where you got this information from, but await is certainly not a No-Op. Calling await on a Task, for example, will invoke a logical call to Task.GetAwaiter, where the TaskAwaiter has to implement INotifyCompletion or ICriticalNotifyCompletion interface, which tells the compiler how to invoke the continuation (everything after the first await).

The complete structure of async-await transforms your call to a state-machine such that when the state-machine hits the first await, it will first check to see if the called method completed, and if not will register the continuation and return from that method call. Later, once that method completes, it will re-enter the state-machine in order to complete the method. And that is logically how you see the line after await being hit.

But, since we are awaiting, does it block the underlying thread resulting thread not being used to execute any tasks?

No, creating an entire mechanism only to block the calling thread would be useless. async-await allows you to actually yield the calling thread back to the caller which allows it to continue execution on that same thread, while the runtime takes care of queuing and invoking the completion.

Ats

Answer 2

In short, no, it doesn't block your thread.

More info: http://blog.stephencleary.com/2013/11/there-is-no-thread.html

Tiffanytiffi

Answer 3

I made a simple async method that calls another async method using await, inside that method is Thread.Sleep(5000). This froze my Winforms UI thread for 5 seconds. So I even though technically it might not block the thread as per other answers, it does block enough within the application itself that it is basically blocking the thread.

public async void start(){ await work(); }
private async Task work(){ Thread.Sleep(5000); }

Will probably have to implement background worker.

EDIT: As per the comment from Damien_The_Unbeliever I added another async nest.

public async void start() { await work(); }
private async Task work() {
    await work2(); // freezes UI - uses UI thread
    await Task.Run(work2); // UI free - uses other thread
    MessageBox.Show("finished"); // Runs after Task.Run finishes
}
private async Task work2() { 
    Thread.Sleep(5000); 
    MessageBox.Show("hi world"); 
}

The await work2() Does nothing, The UI thread becomes unresponsive for 5 seconds. Task.Run() on the otherhand DOES allow the UI thread to run and actually waits before proceeding. This comes with the issues of cross thread accessing of course.

Hybridism

The compiler warning on your work method should already be telling you that this isn't properly using the async feature. async without await is pointless. – Renfrew

Damien_The_Unbeliever I edited the answer and nested into work2 and added more information. work cannot await work2 unless work2 is also async, regardless whether work2 has an await or not. On the face of things await doesn't work as one would assume it works unless it is run with Task.Run instead. Please provide constructive criticism instead. (eg. ... is pointless, but if you do ... it doesnt block the UI thread.) – Hybridism

Answer 4

The thread has a local queue of Tasks. Once it hits an await it will pick up another Task from it's queue (assuming all methods up it's stack are awaited). If the queue is empty, it will try to get a Task from the global queue, and if it's empty too - the thread will try to get a Task from another thread's own local queue. In a simple program, where all threads might get "out of Tasks" - the thread will remain idle until one of the Tasks returns.

Landre