使用异步/等待设计-一切都应该异步吗？

Question

Assume I have an interface method implemented as

public void DoSomething(User user) 
{
    if (user.Gold > 1000) ChatManager.Send(user, "You are rich: " + user.Gold);
}

After some time I realize that I want to change it:

public async Task DoSomething(User user) 
{
    if (user.Gold > 1000) ChatManager.Send(user, "You are rich: " + user.Gold);
    if (!user.HasReward)
    {
         using(var dbConnection = await DbPool.OpenConnectionAsync())
         {
             await dbConnection.Update(user, u => 
                        {
                            u.HasReward = true;
                            u.Gold += 1000;
                        });
         }
    }
}

I'm changing the method signature in the interface. But the calling methods were synchronous and I have to make not only them async but also the whole call tree async.

Example:

void A()
{
    _peer.SendResponse("Ping: " + _x.B());
}

double X.B()
{
    return _someCollection.Where(item => y.C(item)).Average();
}


bool Y.C(int item)
{
   // ...
   _z.DoSomething();
   return _state.IsCorrect;
}

should be changed to

async void AAsync()
{
    _peer.SendResponse("Ping: " + await _x.BAsync());
}

async Task<double> X.BAsync()
{
    // await thing breaks LINQ!
    var els = new List<int>();
    foreach (var el in _someCollection)
    {
        if (await y.CAsync(item)) els.Add(el);
    }
    return _els.Average();
}


async Task<bool> Y.CAsync(int item)
{
   // ...
   await _z.DoSomething();
   return _state.IsCorrect;
}

The affected call tree may be very big (many systems and interfaces) so this change is hard to do.

Also when the first A method is called from interface method like IDisposable.Dispose - I can't make it async.

Another example: imagine that multiple calls to A were stored as delegates. Previously they were just called with _combinedDelegate.Invoke() but now I should go through GetInvocationList() and await on each item.

Oh, and consider also replacing property getter with async method.

I can't use Task.Wait() or .Result because:

1. It's wasting ThreadPool threads in server app
2. It leads to deadlocks: if all ThreadPool threads are Wait ing there are no threads to complete any task.

So the question is: should I make absolutely all my methods initially async even if I'm not planning to call anything async inside? Won't it hurt performance? Or how to design things to avoid such hard refactorings?

Answer 1

should I make absolutely all my methods initially async even if I'm not planning to call anything async inside?

This design problem with async is essentially the same as the problem with IDisposable . That is, interfaces have to predict their implementations. And this is going to be messy, no matter what you do.

In my experience, it's usually rather straightforward to consider a method/interface/class and predict whether it will use I/O or not. If it requires I/O, then it should probably be made task-returning. Sometimes (but not always), it's possible to structure your code so that I/O is done in its own section of the code, leaving business objects and logic strictly synchronous. The Redux pattern in the JavaScript world is a good example of this.

But bottom line, sometimes you make the wrong call and have to refactor. I think this is a far better approach than just making every method asynchronous. Do you make every interface inherit from IDisposable and use using everywhere? Nah, you only add it when necessary; and you should take the same approach with async .

Answer 2

Should I make absolutely all my methods initially async even if I'm not planning to call anything async inside?

No, you should not. Making everything async hurts reading, writing and understanding your code, even if only a little. It could also hurt the performance of your code, especially if you really made every single method (does that include properties?) async .

How to design things to avoid such hard refactorings?

To some degree, such refactorings might be necessary.

But you can avoid a lot of the pain by structuring your code correctly using the single responsibility principle. A method that checks whether state is correct should definitely not send chat messages. This way, changing one method to async shouldn't affect too much code.