CODEWITHSUNDEEP
c#.netwpfdata-bindingasync-await
Peuczynski
Peuczynski

Reputation: 4733

The proper way to await databound property getters c#

What would be the most correct way to use async method in databound property getter? I am talking about solid, scientific arguments, not personal preferences. I've read many threads about the problem, but not this specific case. Some of the solutions don't work in all the cases, and some of the suggestion, well... they were just too subjective or just wrong.

What I don't accept and why:

Problem background (simplified)

Let's say that I am responsible for developing ORM mechanism in a project. There was a first stable version, but now I want to add some properties to the Entities for the DataBinders who are responsible for the layout. I can edit Entity layer, but I can't edit Mapping and Repository layers. (I am not held againt my will, this situation is fictional simplification). All the methods in repositories are async. All I can do is ask someone responsible to provide identical synchronous methods for all of the methods, but it would be stupid to this kind of redundant work.

Only solution I can use now

_something = Task.Run(async () => await AnotherRepository.CalculateStuff(this)).Result;

And it just doesn't look right to me. It works, but I have to await my method inside the lambda in Task.Run(). I am stuck with it for the time being, and I want to know the simplest and correct approach.

Repository method pseudo-code

public async static Task<IList<CalculatedStuff>> CalculateStuff(SomeClass class)
{
    return await Task.Run(() =>
    {
        using (var session = Helper.OpenSession())
            return session.CreateCriteria(typeof(CalculatedStuff)).Add(Restrictions.Eq("SomeClass", class))
                ///...
                .List<CalculatedStuff>();
    });
}

Upvotes: 0

Views: 1420

Answers (2)

Stephen Cleary
Stephen Cleary

Reputation: 456547

there are no such things like async properties

I have a blog post and MSDN article on "async properties" for data binding. I do take the stance that they are not natural, which is based on these (objective) observations:

  • Properties read by data binding must return immediately (synchronously).
  • Asynchronous operations are asynchronous (that is, they complete after some time).

Clearly, these are at complete odds with one another.

Now, there are a few different solutions, but any solution that attempts to violate one of these observations is going to be dubious, at best.

For example, you can attempt to violate the second observation by trying to run the asynchronous operation synchronously. As you discovered, Result / Wait / GetAwaiter().GetResult() will deadlock (for reasons described in detail on my blog). Task.Run(() => ...).GetAwaiter().GetResult() will avoid the deadlock but will execute the code in a free-threaded context (which is OK for most code but not all). These are two different kinds of sync-over-async; I call them the "Blocking Hack" and the "Thread Pool Hack" in my Async Brownfield article, which also covers two other kinds of sync-over-async patterns.

Unfortunately, there is no solution for sync-over-async that works in every scenario. Even if you get it to work, your users would get a substandard experience (blocking the UI thread for an indefinite amount of time), and you may have problems with app stores (I believe MS's at least will actively check for blocking the UI thread and auto-reject). IMO, sync-over-async is best avoided.

However, we obviously cannot violate the first observation, either. If we're data binding to the result of some asynchronous operation, we can't very well return it before the operation completes!

Or can we?

What if we change what the data binding is attaching to? Say, introduce a property that has a default value before the operation is completed, and changes (via INotifyPropertyChanged) to the result of the operation when the operation completes. That sounds reasonable... And we can stick in another property to indicate to the UI that the operation is in progress! And maybe another one to indicate if the operation failed...

This is the line of thinking that resulted in my NotifyTaskCompletion type in the article on data binding (updated NotifyTask type here). It is essentially a data-bindable wrapper for Task<T>, so the UI can respond dynamically to the asynchronous operation without trying to force it to be synchronous.

This does require some changes to the bindings, but you get a nice side effect that your UX is better (non-blocking).

This should me method, not property

Well, you can do this as a property:

TEntity Entity { get { return NotifyTask.Create(() => Repository.GetEntityAsync()); } }
// Data bind to Entity.Result for the results.
// Data bind to Entity.IsNotCompleted for a busy spinner.

However, I would say that it's surprising behavior to have a property read kick off something significant like a database query or HTTP download. That's a pretty wide definition of "property". IMO, this would be better represented as a method, which connotates action more than a property does (or perhaps as part of an asynchronous initialization, which I also describe on my blog). Put another way: I prefer my properties without side effects. Reading a property more than once and having it return different values is counterintuitive. This final paragraph is entirely my own opinion. :)

Upvotes: 2

Evk
Evk

Reputation: 101483

If you have access to the source code of AnotherRepository.CalculateStuff, you can implement it in a way that won't deadlock when called from bound property. First short summary of why it deadlocks. When you await something, current synchronization context is remembered and the rest of the method (after async) is executed on that context. For UI applications that means the rest of the method is executed on UI thread. But in your case UI thread is already blocked by waiting for the Result of task - hence deadlock.

But there is method of Task named ConfigureAwait. If you pass false for it's only argument (named continueOnCapturedContext) and await task returned by this method - it won't continue on captured context, which will solve your problem. So suppose you have:

 // this is UI bound
 public string Data
 {
     get { return GetData().Result; }
 }

 static async Task<string> GetData() {
     await Task.Run(() =>
     {
         Thread.Sleep(2000);
     });
     return "test!";
 }

This will deadlock when called from UI thread. But if you change it:

 static async Task<string> GetData() {
     await Task.Run(() =>
     {
         Thread.Sleep(2000);
     }).ConfigureAwait(false);
     return "test!";
 }

It won't any more.

For those who might read this later - don't do it this way, only if for temporary debugging purposes. Instead return dummy object from your property getter with some IsLoading flag set to true, and meanwhile load data in background and fill dummy object properties when done. This will not freeze your UI during long blocking operation.

Upvotes: 1

Related Questions