CODEWITHSUNDEEP
c#task-parallel-library
Steve
Steve

Reputation: 4453

Task is asynchronous or synchronous without async await?

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.

Upvotes: 2

Views: 442

Answers (1)

Peter Duniho
Peter Duniho

Reputation: 70652

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.

Upvotes: 2

Related Questions