What exactly happens when you call an async method without the await keyword?

Question

I have a web server and there is a periodic job merges and send records (lots of request logs).

Task.Run(() => { while (true) { try { MergeAndPutRecords(); } catch (Exception ex) { Logger.Error(ex); } } });

In MergeAndPutRecords function, there are code merging records and async function returns Task sending records. (Actaully it is Amazon Kinesis Firehose's PutRecordBatchAsync.)

Then what happens if i call that function without await keyword? Does function runs on seperated thread? Here says it is not. Then what is returning Task Means? Here says async method without await keyword means

Starts the asynchronous method on the current thread. Ignores all results (including exceptions).

Then my periodic job and PutRecordBatchAsync are processed concurrently? I know asynchronouse and concurrent is different. But there is no await keyword and they are in same thread. Which one would be executed first? I'm confusing...

There would be massive records that needs to be merge and sent in real-time. So I think it must be executed concurrently..

async keyword doesn't do anything by itself. Each await gets combined into a AsyncStateMachine that can process stuff asynchronously. If you don't have await keyword inside async method then there is no reason to create AsyncStateMachine, so you get synchronous method. — FCin
– FCin, Commented Dec 22, 2017 at 8:56
await is used to wait for a result to arrive. It does not, in any way, control how the process to obtain the result was started or how the ongoing process to obtain the result is working. — Damien_The_Unbeliever
– Damien_The_Unbeliever, Commented Dec 22, 2017 at 8:57

Mrinal Kamboj · Accepted Answer · 2017-12-22 10:39:05Z

Then my periodic job and PutRecordBatchAsync are processed concurrently?

Using Task API you can ensure that they are executed concurrently (using Thread pool), but you need to understand the difference between in memory concurrent operations Vs IO based concurrency.

While In memory concurrency does benefit using Tasks, IO call once executed doesn't need thread at all, as it relies on hardware concurrency, if it ever use the thread, all that it would do it wait for the IO call to return, thus wasting the precious system resources and reducing system scalability

You case is that IO based concurrency, as you call a remote / network based API, how does async-await helps here ?

Well true Async operation will free up the thread context, on windows it would use IO completion port (queuing mechanism) to execute the Async call, while the calling thread is used to dispatch other similar calls, it would just need thread context on return of the IO call for serving the response and for that too, if its not a UI call, then use ConfigureAwait(false), so that any thread context can be used to deliver the response.

What if you don't use await with async ?

The call meant to be Asynchronous becomes Synchronous and would immediately impact the system scalability, as threads are now blocked, even worse for a long running IO operations. Have you seen how JavaScript frameworks always make a AJAX (Async) call to the server API, thus much more work is possible W/o blocking the Browser threads.

In general for In memory processing you would create certain number of Tasks and process them using Task.WaitAll or Parallel.ForEach for a collection, for Async processing, ideally recommendation is not to have a Task.Run anywhere, its preferred to have to Async from the entry point, like its possible in case of MVC, controllers can be async. Multiple calls are grouped together using Task.WhenAll representative Task and then awaited upon. even if you use Task.Run as in your code, then use async lambda to execute an asynchronous call

Summary :

Its mandatory to use await for asynchronous calls, else they async keyword is useless in that context and yes await will wait for the IO call to return before continuation is executed, though no thread is blocked in the process

"The call meant to be Asynchronous becomes Synchronous and would immediately impact the system scalability, as threads are now blocked" - I believe this is either incorrect or unclear. Yes, the call to the async function returns synchronously, but conceptually it always did; the asynchronicity "happens" at the await statement. If await doesn't exist, the caller proceeds past the asychronous function out of order. If the Task has a continuation, it still runs, but is effectively headless; results and exceptions are ignored.
(3/3) Thus, most genuine case for Async processing remains IO processing and here we can use ConfigureAwait(false) to ensure that returning call can execute on any available thread, instead of waiting for same thread context for reentry and that's a performance optimization. Also Exception and Result are not ignored but are available on explicit access of Task, which is by design in the .Net 4.5, it was different in the earlier versions, when exceptions used to propagate automatically like any other logical code
I don't understand the "benefit" you are saying will be lost. If we know the method need not be awaited, we don't reduce scalability by not awaiting it. Note the question is about an async method, not an async call. If an async method takes out the trash and is guaranteed to be complete in less than an hour, and the return value is how the trash smelled when it was taken out, it's quite acceptable to "fire and forget" the task once every week if we feel it meets our requirements.
@MrinalKamboj the OP is not implying the use of Task.Wait() or Task.Result instead of using await. Rather, they are asking what happens if await is elided from the code. If await is elided, there is no blocking or scaling issue and the task executes at some point in the future when the TaskScheduler gets around to it. It effectively becomes a "fire and forget" task whose exceptions go to the TaskScheduler.UnobservedExceptions and are ignored.
@MrinalKamboj the ThreadPool is not used unless you use Task.Run() with it. Eliding awaitstarts the asynchronous method on the current thread. Ignores all results (including exceptions). - see here: stackoverflow.com/a/46245804/251267

Gusdor · Accepted Answer · 2017-12-22 09:18:15Z

If a method returns a Task, it is always best practice to observe the result of that Task at some point. It may be the declared return value, or it may be an exception. If you want to observe that task before your method continues, await is the recommendation.

In this case, you should probably be observing the result of the Task returned by PutRecordBatchAsync. You will want to know if the call failed for any reason as this probably indicates that your records were not stored!

In the example code you gave, you will find that you make subsequent calls to MergeAndPutRecords before the previous call is complete. Are you sure that this is intended?

Collectives™ on Stack Overflow

What exactly happens when you call an async method without the await keyword?

2 Answers 2

12 Comments

Comments

Linked

Hot Network Questions

Collectives™ on Stack Overflow

2 Answers 2

12 Comments

Comments

Linked

Related