await vs Task.Wait - Deadlock?

Question

I don't quite understand the difference between Task.Wait and await.

I have something similar to the following functions in a ASP.NET WebAPI service:

public class TestController : ApiController
{
    public static async Task<string> Foo()
    {
        await Task.Delay(1).ConfigureAwait(false);
        return "";
    }

    public async static Task<string> Bar()
    {
        return await Foo();
    }

    public async static Task<string> Ros()
    {
        return await Bar();
    }

    // GET api/test
    public IEnumerable<string> Get()
    {
        Task.WaitAll(Enumerable.Range(0, 10).Select(x => Ros()).ToArray());

        return new string[] { "value1", "value2" }; // This will never execute
    }
}

Where Get will deadlock.

What could cause this? Why doesn't this cause a problem when I use a blocking wait rather than await Task.Delay?

@Servy: I will get back with a repo as soon as I have time. For now it works with `Task.Delay(1).Wait()` which is good enough. — ronag, Oct 30 '12 at 14:36
`Task.Delay(1).Wait()` is basically the exact same thing as `Thread.Sleep(1000)`. In actual production code it is rarely appropriate. — Servy, Oct 30 '12 at 14:38
@ronag: Your `WaitAll` is causing the deadlock. See the link to my blog in my answer for more details. You should use `await Task.WhenAll` instead. — Stephen Cleary, Oct 30 '12 at 15:01
Your code is deadlocking because you're blocking on the results of an asynchronous operation, just as the link in Stephen's answer shows. You need to `await` all the way up for it to work. Likewise, you can block all the way down and it will work. In your example where you block you actually never *actually* `await`, you block all the way, so it won't deadlock (it also blocks the thread during the asynchronous operation rather than leaving the thread free). — Servy, Oct 30 '12 at 15:01
I don't quite understand I am doing `ConfigureAwait(false)` as shown in the link you refer to. I cannot use async all the way up as that would require to much code changes in my actual code. — ronag, Oct 30 '12 at 15:03
@ronag Because you have `ConfigureAwait(false)` a *single* call to `Bar` or `Ros` won't deadlock, but because you have an enumerable that is creating more than one and then waiting on all of those, the first bar will deadlock the second. If you `await Task.WhenAll` instead of waiting on all of the tasks, so that you don't block the ASP context, you'll see the method return normally. — Servy, Oct 30 '12 at 15:10
@ronag Your other option would be to add the `.ConfigureAwait(false)` *all the way up the tree* until you block, that way nothing is *ever* trying to get back to the main context; that would work. Another option would be to spin up an inner synchronization context. [Link](http://blogs.msdn.com/b/pfxteam/archive/2012/02/02/await-synchronizationcontext-and-console-apps-part-3.aspx). If you put the `Task.WhenAll` in an `AsyncPump.Run` it will effectively block on the whole thing without you needing to `ConfigureAwait` anywhere, but that's probably an overly-complex solution. — Servy, Oct 30 '12 at 15:16
Possible duplicate of [What's the difference between Task.Start/Wait and Async/Await?](http://stackoverflow.com/questions/9519414/whats-the-difference-between-task-start-wait-and-async-await) — ruffin, Apr 05 '17 at 19:42

score 377 · Accepted Answer · edited Oct 31 '18 at 07:52

377

Wait and await - while similar conceptually - are actually completely different.

Wait will synchronously block until the task completes. So the current thread is literally blocked waiting for the task to complete. As a general rule, you should use "async all the way down"; that is, don't block on async code. On my blog, I go into the details of how blocking in asynchronous code causes deadlock.

await will asynchronously wait until the task completes. This means the current method is "paused" (its state is captured) and the method returns an incomplete task to its caller. Later, when the await expression completes, the remainder of the method is scheduled as a continuation.

You also mentioned a "cooperative block", by which I assume you mean a task that you're Waiting on may execute on the waiting thread. There are situations where this can happen, but it's an optimization. There are many situations where it can't happen, like if the task is for another scheduler, or if it's already started or if it's a non-code task (such as in your code example: Wait cannot execute the Delay task inline because there's no code for it).

You may find my async / await intro helpful.

edited Oct 31 '18 at 07:52

Mario S

11,715
24
39
47

answered Oct 30 '12 at 14:19

Stephen Cleary

437,863
77
675
810

9

I think there is a missunderstanding, `Wait` works fine `await` deadlocks. – ronag Oct 30 '12 at 14:20
I don't mean that the task I'm waiting on may execute on the waiting thread. What I mean is that while waiting the task scheduler will execute other tasks on the thread that called `Wait`. – ronag Oct 30 '12 at 14:22
2

Clearly: Yes, if I replace my `await Task.Delay(1)` with `Task.Delay(1).Wait()` the service works fine, otherwise it deadlocks. – ronag Oct 30 '12 at 14:23
6

No, the task scheduler won't do that. `Wait` blocks the thread, and it cannot be used for other things. – Stephen Cleary Oct 30 '12 at 14:23
Clearly: Interesting, I wouldn't have thought that, and I'm a bit surprised. In PPL/Concrt any blocking operation is cooperative as I have described. – ronag Oct 30 '12 at 14:24
I'm not able to get your `await`-based code to deadlock on my machine. Could you provide a repo? – Stephen Cleary Oct 30 '12 at 14:30
There is quite a lot of code go through to create a repo. I will try to provide a repo, though that will have to wait a while until I have time. It works right now, which is good enough for now, though I am very curious about what the problem with `await` might be. – ronag Oct 30 '12 at 14:34
9

@ronag My guess is you just got your method names mixed up and your deadlock was actually caused with the blocking code and worked with the `await` code. Either that, or the deadlock was unrelated to either and you mis-diagnosed the problem. – Servy Oct 30 '12 at 14:37
Did the .NET team drop the ball on this deadlock issue when they let the context to be blocked and also allow the scheduling of the continuation on the same context or is this by design? – Stack Undefined Dec 06 '16 at 17:45
4

@hexterminator: This is by design - it works great for UI apps, but does tend to get in the way for ASP.NET apps. ASP.NET Core has fixed this by removing the `SynchronizationContext`, so blocking within an ASP.NET Core request no longer deadlocks. – Stephen Cleary Dec 06 '16 at 19:19
@StephenCleary Can we overcome deadlocks by using await Task.WaitAll() instead of using Task.WaitAll() please? – AfshinZavvar May 17 '17 at 06:58
@Afshin_Zavvar: Blocking on asynchronous code *must* either allow deadlocks or reentrancy. There is no clean solution. – Stephen Cleary May 17 '17 at 13:34
1

on msdn here, it says that wait runs on separate thread asynchronously. Am I missing something? https://msdn.microsoft.com/en-us/library/hh195051(v=vs.110).aspx – Emil Jul 05 '17 at 01:15
@batmaci: That's talking about `Task.Run`, not `async`/`await`. – Stephen Cleary Jul 05 '17 at 14:04
@StephenCleary so I wanted to know, like in msdn article. this code will run async in sync wrapper? var t = Task.Run(() => { Console.WriteLine("Task thread ID: {0}", Thread.CurrentThread.ManagedThreadId); } ); t.Wait(); – Emil Jul 05 '17 at 14:08
@batmaci: If by "this code", you mean the code in this question and answer, then no, it is not async-over-sync. If by "this code", you mean the code posted in your comment on this answer, then yes, it runs async-over-sync. – Stephen Cleary Jul 05 '17 at 17:48
1

So how do we get around this if we can't use an async entry point .. which seems to be pretty common? – Joe Phillips Sep 05 '17 at 13:41
2

@JoePhillips: See the hacks in my [brownfield async article](https://msdn.microsoft.com/en-us/magazine/mt238404.aspx). – Stephen Cleary Sep 05 '17 at 17:03
@Joe Phillips: Another approach is wrap sync implementation: public async Task DoAsync(long id) { return await Task.Run(() => { return DoSync(id); } ); } I do not see why I'm must live with the code duplication. – user1785960 Apr 20 '20 at 12:34
@user1785960: The [thread pool hack](https://msdn.microsoft.com/en-us/magazine/mt238404.aspx) does not work in all cases. Check out the brownfield async article for an approach that is not a hack and does not cause code duplication. – Stephen Cleary Apr 20 '20 at 16:54
3

@StephenCleary That's so trippy. I'm here because I'm having trouble understanding a bit of the Concurrency in C# Cookbook where you you first mention deadlocks, and after some time I realize that you're the author. – adamasan Apr 26 '20 at 23:41
1

@artie: If you have any recommendations on how to make the book better, I'd love to hear them! – Stephen Cleary Apr 27 '20 at 01:51
@Stephen Cleary: This is not true: " Wait blocks the thread, and it cannot be used for other things." public bool Wait(int millisecondsTimeout); So It can be used for other tings and block only for some timeout. We can tell client: the task take to long time and you should ask about product leter. – user1785960 Jul 08 '20 at 11:06
2

@user1785960: "`Wait` blocks the thread for the duration of the call, and while that blocking is occurring, the thread cannot be used for other things." - How's that? – Stephen Cleary Jul 08 '20 at 12:44

score 30 · Answer 2 · edited Feb 13 '20 at 11:40

30

Based on what I read from different sources:

An await expression does not block the thread on which it is executing. Instead, it causes the compiler to sign up the rest of the async method as a continuation on the awaited task. Control then returns to the caller of the async method. When the task completes, it invokes its continuation, and execution of the async method resumes where it left off.

To wait for a single task to complete, you can call its Task.Wait method. A call to the Wait method blocks the calling thread until the single class instance has completed execution. The parameterless Wait() method is used to wait unconditionally until a task completes. The task simulates work by calling the Thread.Sleep method to sleep for two seconds.

This article is also a good read.

edited Feb 13 '20 at 11:40

David Ferenczy Rogožan

23,966
9
79
68

answered Dec 06 '18 at 13:52

Ayushmati

1,455
1
13
15

3

"Isn't that technically incorrect then? Can someone please clarify?" - can I clarify; are you asking that as a question? (I just want to be clear whether you're asking vs answering). If you're asking: it may work better as a separate question; it is unlikely to gather new responses here as an answer – Marc Gravell Dec 06 '18 at 13:54
1

I have answered the question and asked a separate question for the doubt I had here https://stackoverflow.com/questions/53654006/using-task-wait-instead-of-await-for-async-programming Thanks @MarcGravell. Can you please remove your deletion vote for the answer now? – Ayushmati Dec 06 '18 at 15:03
"Can you please remove your deletion vote for the answer now?" - that isn't mine; thanks to the ♦, any such vote by me would have taken effect immediately. I don't, however, think that this answers the key points of the question, which is about the deadlock behaviour. – Marc Gravell Dec 06 '18 at 15:30
1

This is not true. Until first await not reached everything is blocked – user1785960 Jul 08 '20 at 10:56
@user1785960 though you are right, it doesn't mean the fact the answer is useless. – Soner from The Ottoman Empire Dec 11 '20 at 18:05
Using async await does not create a thread technically and will cause your code to share the thread as opposed to Task/Thread. Async is used for not blocking the UI, Threads are used for non-UI block logic – Nick Turner Mar 16 '23 at 13:33

score 6 · Answer 3 · edited Jan 27 '23 at 16:47

Some important facts were not given in other answers:

async/await is more complex at CIL level and thus costs memory and CPU time.

Any task can be canceled if the waiting time is unacceptable.

In the case of async/await we do not have a handler for such a task to cancel it or monitoring it.

Using Task is more flexible than async/await.

Any sync functionality can by wrapped by async.

public async Task<ActionResult> DoAsync(long id) 
{ 
    return await Task.Run(() => { return DoSync(id); } ); 
}

async/await generate many problems. We do not know if await statement will be reached without runtime and context debugging. If first await is not reached, everything is blocked. Sometimes even when await seems to be reached, still everything is blocked:

https://github.com/dotnet/runtime/issues/36063

I do not see why I must live with the code duplication for sync and async method or using hacks.

Conclusion: Creating Tasks manually and controlling them is much better. Handler to Task gives more control. We can monitor Tasks and manage them:

https://github.com/lsmolinski/MonitoredQueueBackgroundWorkItem

Sorry for my english.

await vs Task.Wait - Deadlock?

3 Answers3

Linked

Related