If I have task
without async await
, will my task
consider asynchronous or synchronous? In Microsoft doc, it says The tasks run asynchronously and may complete in any order.
but in one stackoverflow post, it says Wait will synchronously block until the task completes. So the current thread is literally blocked waiting for the task to complete.

- 2,963
- 15
- 61
- 133
-
4The SO post is talking about the `Wait()` method on the Task, if it is called the calling Thread will wait for the execution to be done. If not then the calling thread will move on (but do not call `Wait()` manually, you should always await Tasks). Here are 2 videos that helped me understand async/ await: 1. https://www.youtube.com/watch?v=2moh18sh5p4 2. https://www.youtube.com/watch?v=J0mcYVxJEl0 – MindSwipe Nov 01 '19 at 12:32
-
But if I call the task with await, then the task run asynchronously as well? – Steve Nov 01 '19 at 12:56
-
2@Steve that is undefined, and is entirely up to whatever the implementation is; the caller doesn't get a vote – Marc Gravell Nov 01 '19 at 13:03
-
I think I got it. If call a task with `Wait()`, then will the task run `synchronously` while call a task with `await` (which combo with async), then the task run `asynchronously` – Steve Nov 01 '19 at 13:47
-
1@Steve It depends on what you mean with the “task runs asynchronously”. Like Marc said, the actually called task/async method runs the same as it doesn’t know how it was called. The only thing that changes is how the caller behaves. If you use await the compiler will transform your calling method to behave asynchronously, if you just call Wait it doesn’t transform the calling method and the calling method will wait synchronously. – ckuri Nov 01 '19 at 15:18
1 Answers
Task is asynchronous or synchronous without async await?
That depends entirely on the Task
itself, and will have nothing to do with whether you use await
or not.
When you use Task.Run()
to create a new task, that queues a worker to the thread pool, and it will run asynchronously. But, you can also get a Task
object from the Task.FromResult()
method, which trivially returns a completed task synchronously.
In between those two extremes are things like async
methods that sometimes complete synchronously and sometimes don't (e.g. reading data from a file or network, where sometimes the data is already buffered and available and other times it won't be available until later).
The Stack Overflow post you mention doesn't have anything to do with the asynchronous nature of a task, but rather what happens depending on how you wait for the task to complete. Of course, synchronously-completed task objects are already completed by the time you have a reference to the object, so "waiting" on such an object never actually blocks anything. So the interesting case are task objects which are not already completed, i.e. which are going to complete asynchronously.
In those cases, the Wait()
method will block the current thread. That's by design, and is clearly documented as such. This is almost never what you want. But it's important to note that even if you use Wait()
, the task itself is still asynchronous. You may have blocked the current thread, but other things are still happening in your process, including whatever it is that task represents. Those things are happening asynchronously with your current thread.
The fact that you've chosen to make your current thread do nothing, doesn't change the inherently asynchronous nature of the task you started.
More typically, you will use await
to effectively register your request to have the current method resume execution later, in the current synchronization context, once the task completes. At the await
statement, the current method will yield the thread back to the caller, allowing it to go on to do other things. In that case, the task is still being completed asynchronously, just as if you'd used Wait()
and blocked the thread, but now your current thread also has the opportunity to do something else.
In both cases, the task itself is still asynchronous. The way you've waited on it does not have any effect on that.
IMHO, it makes less sense to worry about whether the task is asynchronous or not. Your code should work the same regardless. Instead, view the task as a "promise" to provide a result at some point in the future. Indeed, the words "promise" and "future" are often used instead of "task" in other programming environments, to represent the same thing. Sometimes that promise is fulfilled immediately, sometimes it takes awhile, but it really doesn't matter to you which happens. What's important is the promise itself, not how or exactly when the promise will be kept.

- 68,759
- 7
- 102
- 136