In other words, is
var task = SomeLongRunningOperationAsync();
task.Wait();
functionally identical to
SomeLongRunningOperation();
Stated another way, is
var task = SomeOtherLongRunningOperationAsync();
var result = task.Result;
functionally identical to
var result = SomeOtherLongRunningOperation();
According to Task.Wait and Inlining, if the Task being Wait
’d on has already started execution, Wait
has to block. However, if it hasn’t started executing, Wait
may be able to pull the target task out of the scheduler to which it was queued and execute it inline on the current thread.
Are those two cases merely a matter of deciding which thread the Task is going to run on, and if you're waiting on the result anyway, does it matter?
Is there any benefit to using the asynchronous form over the synchronous form, if nothing executes between the asynchronous call and the Wait()
?
Here are some differences:
AggregateException
. The exception stack will be different.HttpContext.Current
(which is not actually thread-local but almost), might be different.Task
induces a memory barrier which can have a synchronizing effect.Does this matter? Decide for yourself by this list.
Are there benefits to doing this? I can't think of any. If your computation uses async IO the wait will negate the benefits that the async IO brings. The one exception would be fan-out IO, e.g. issuing 10 HTTP requests in parallel and waiting for them. That way you have 10 operations at the cost of one thread.
Note, that Wait
and Result
are equivalent in all these regards.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With