Async-await seems to use the UI thread

Question

In a view-model I use a factory:

private async Task<BaseData> InitializeAsync()
{
    await InstancesAsync();
    await ProjectsAsync();
    await AdminAsync();
    return this;
}
public static async Task<BaseData> CreateAsync()
{
    var ret = new BaseData();
    return await ret.InitializeAsync();
}

The awaited methods are rather staightforward, with e.g.

 var instances = await TaskEx.Run(new Func<List<string>>(() => Agent.GetInstances()));

In the wpf view I want to set the DataContext in the constructor:

Loaded += delegate
{
    Dispatcher.Invoke(new Action(async () => { DataContext = await BasisGegevens.CreateAsync(); }));
};

Although it works, I feel rather uncomfortable because the UI thread is used everywhere, also after the callbacks when the awaits complete. What am I missing?

Also I don't understand how to use the factory pattern for the DataContext because without the Invoke above I get the error that a different thread owns the object.

EDIT: using the ideas of Mr. Cleary I get:

Loaded += async (object sender, RoutedEventArgs e) =>
          { DataContext = await BaseData.CreateAsync(); };
public static Task<BaseData> CreateAsync()
{
    var ret = new BaseData();
    return ret.InitializeAsync();
}
private async Task<BaseData> InitializeAsync()
{
    // UI thread here
    await InstancesAsync().ConfigureAwait(false);
    // thread 'a' here
    await ProjectsAsync().ConfigureAwait(false);
    // thread 'a' sometimes 'b' here
    await AdminAsync().ConfigureAwait(false);
    // thread 'a' or 'b' here
    return this;
}

This works fine, except I cannot understand how ConfigureAwait(false) works.
Inside the method InstancesAsync() I have the awaited task:
var instances = await TaskEx.Run(new Func<List<string>>(() => Agent.GetInstances()));
After awaiting the repsonse, I return in the UI thread - I never expected that to happen!
Note that ProjectsAsync() and AdminAsync() behave the same, although they start on a worker (or background) thread!
I thougth that ConfigureAwait(true) has the effect of returning in the calling thread (in my case UI thread). I tested that and it is so.
Why do I see this with ConfigureAwait(false) too: because of a nested await, see comments.

What is the source of the `Loaded` event in the code you showed? If this is a regular [`FrameworkElement.Loaded`](http://msdn.microsoft.com/en-us/library/system.windows.frameworkelement.loaded(v=vs.110).aspx) event, it should be fired on the UI thread. Are you creating a view on a separate thread? Is that perhaps because you're calling `Agent.GetInstances()` on a non-UI pool thread? — noseratio, Nov 18 '13 at 21:20
The Loaded event is a regular FrameworkElement.Loaded event. I intended to create the view on the UI thread, that apparantly was wrong. Agent.GetInstances() runs in an awaited task, I expected it to be on a non-UI pool thread, but it wasn't. — Gerard, Nov 19 '13 at 08:16
`TaskEx.Run` does use a separate pool thread to run your `Func` delegate, that's where `Agent.GetInstances()` is executed. I'd suggest you follow Stephen's answer and make sure both WPF UI elements and ViewModel objects are all created on the same - UI - thread. Add some logging (`System.Threading.Thread.CurrentThread.ManagedThreadId`) to see what thread you're on and where. — noseratio, Nov 19 '13 at 08:29
`ConfigureAwait(false)` only affects that specific `await`, it has no effect on `await`s that are “inside” it. — svick, Nov 19 '13 at 10:26

score 7 · Accepted Answer · answered Nov 19 '13 at 01:30

I find it most useful to treat the ViewModel as having UI thread affinity. Think of it as the logical UI, even if it's not the actual UI. So all property and observable collection updates on ViewModel classes should be done on the UI thread.

In your async methods, if you don't need to return to the UI thread, then you can use ConfigureAwait(false) to avoid resuming on the UI thread. For example, if your various initialization methods are independent, you could do something like this:

private async Task<BaseData> InitializeAsync()
{
  // Start all methods on the UI thread.
  var instancesTask = InstancesAsync();
  var projectsTask = ProjectsAsync();
  var adminTask = AdminAsync();

  // Await for them all to complete, and resume this method on a background thread.
  await Task.WhenAll(instancesTask, projectsTask, adminTask).ConfigureAwait(false);

  return this;
}

Also, any time you have return await, take another look to see if you can just avoid async/await entirely:

public static Task<BaseData> CreateAsync()
{
  var ret = new BaseData();
  return ret.InitializeAsync();
}

Finally, you should strongly avoid Dispatcher. Your Loaded event could be simplified to this:

Loaded += async ()
{
  DataContext = await BasisGegevens.CreateAsync();
};

I derived `return await` from your factory pattern at 'http://blog.stephencleary.com/2013/01/async-oop-2-constructors.html'. — Gerard, Nov 19 '13 at 08:26
The Loaded delegate I must write as `async (object sender, RoutedEventArgs e)` for it to compile. — Gerard, Nov 19 '13 at 08:44

Async-await seems to use the UI thread

1 Answers1

Linked