Reputation: 17367
A lot of API's are moving toward exposing only asynchronous methods. How much of a performance hit is there in scenarios where you have to immediately wait on these methods? Am I wrong in assuming that it causes the current thread to wait on a spawned thread to complete? Or does the CLR perform some sort of magic in these scenarios and make it all execute in the same thread?
Upvotes: 0
Views: 274
Reputation: 39085
By "asynchronous methods", I assume you mean Task<T>
based async methods.
So if you have a method that returns a Task<T>
and you immediately call its Wait()
method, that causes the current that to wait on an internal WaitHandle
object. The task most likely executes on a different thread and signals the WaitHandle
when completed, which releases the waiting thread. There is no compliler optimization that turns this scenario into a synchronous call that I'm aware of.
This is of course more work than just calling a synchronous equivalent of the async method. However,depending on your use case, it probably won't be a significant difference.
The more important question is why would you want to loose the advantages of async by blocking the calling thread? That is generally not a good idea, you should ensure you have a very good reason to do this.
Upvotes: 3