将 function 标记为异步但没有等待调用，有什么问题吗？

Question

Are there any side effects to having a function that is marked as async, but it doesn't actually make any await calls? Eg:

public interface IMyInterface
{
    Task DoSomethingAsync();
}

public class DoSomething1:IMyInterface
{
    public async Task DoSomethingAsync()
    {
        await getSomethingFromDatabaseAsync();
    }
}

public class DoSomething2:IMyInterface
{
    public async Task DoSomethingAsync()
    {
        doSomethingElse();
    }
}

IMyInterface is implemented by quite a few classes, but for one of the classes there are no await calls. Will this cause any problems?

Answer 1

In the case where you have an interface method that returns a task and you have no awaits (yeah it happens). Just remove the async keyword and return Task.CompletedTask

The Task.CompletedTask property returns a task whose Status property is set to RanToCompletion .

Gets a task that has already completed successfully.

public class DoSomething2:IMyInterface
{
    public Task DoSomethingAsync()
    {
        doSomethingElse();
        return Task.CompletedTask;
    }
}

Yes there are side affects, the compiler is plumbing up the IAsyncStateMachine and produces a bunch more IL , additionally future developers will look at your code with ire . As for other functional differences, I can't think of any off hand.

Answer 2

IMyInterface is implemented by quite a few classes, but for one of the classes there are no await calls. Will this cause any problems?

I'm going to enter dangerous territory here and disagree with Eric Lippert. In the vast majority of cases, using async without await is indeed a mistake and the compiler warning is useful. I'd say this is true well north of 90% of the time.

However, I'd say this scenario is an exception to that rule. The problem with just dropping async / await is that exceptions are handled quite differently:

public Task DoSomethingAsync()
{
  // if doSomethingElse throws, that exception is raised directly;
  // it is *not* captured and placed on the returned task!
  doSomethingElse();
  return Task.CompletedTask;
}

The expected semantics for a Task -returning method is that exceptions are captured and placed on the returned Task (well, at least non- bone-headed exceptions). To keep these semantics, you need to either use async (and suppress the warning) or an explicit try / catch :

#pragma warning disable 1998
public async Task DoSomethingAsync()
#pragma warning restore 1998
{
  doSomethingElse();
}

// or

public Task DoSomethingAsync()
{
  try
  {
    doSomethingElse();
    return Task.CompletedTask;
  }
  catch (Exception ex)
  {
    return Task.FromException(ex);
  }
}

Answer 3

In your case, I think there might be a problem of blocking the main thread (and it depends if you care or not) and I think this is not a developer wants.

If you do not have any await calls, you can do the below so that the main thread will not be blocked (> .net 4.0):

public class DoSomething2:IMyInterface
{
     public async Task DoSomethingAsync()
     {
         await Task.Run(()=>doSomethingElse());
     }
}

Answer 4

Methods marked as async will work the same way it will just create a bit overhead, because when method is marked as async compiler basically generates state machine for that method.( which in your case wont be use in some particular methods )

https://foreverframe.net/what-lies-beneath-asyncawait-in-c/

https://msdn.microsoft.com/en-us/magazine/jj991977.aspx