There is a common misconception that when you make a method async
, it will be actually executed asynchronously (i.e. on a separate thread). That is not the case: async
and await
are a means to synchronize already asnychronous code. If you have nothing that is executed on a separate thread, your async
code will run fully synchronously to the end.
Since getDataAsync
is executed on the same thread as the MyViewModel
constructor, you can run into a deadlock, since the thread waits for itself. When you use ConfigureAwait
, you can avoid this situation.
Whether you actually should do that is a different question. What you are actually doing with ConfigureAwait
is to start the task and to allow the await to continue on a separate context (which can be on a separate thread). Apart from the fact that you are not even using await
here, continuation in a different context can become a problem when you want to execute UI operations after the await.
If you want to be sure that you can wait for getDataAsync
in your constructor, you can use Task.Run
to force execution in the thread pool:
var getDataTask = Task.Run((Func<Task>)getDataAsync);
//Do something else
getDataTask.Wait();
Everything you execute between Task.Run
and the Wait()
can run during the execution of getDataAsync
. Whether parallelism is actually worth it here depends on what else you do until the Wait()
.
What you are doing in the MyViewModel
constructor is to finally synchronize all asynchronous operations and make the execution of the constructor synchronous. If you want to run that operation asynchronously, you would need to start another task to do it. So you should be really sure that beyond that point async
is not required anymore. If it is, run the initialization on another async
method, await getDataAsync()
there and synchronize somewhere up the call chain.