In documentation here: http://msdn.microsoft.com/en-us/library/hh191443.aspx it indicates that:
If an async method doesn’t use an await operator to mark a suspension
point, the method executes as a synchronous method does, despite the
async modifier. The compiler issues a warning for such methods.
I believe this is the warning:
This async method lacks 'await' operators and will run synchronously.
Consider using the 'await' operator to await non-blocking API calls,
or 'await Task.Run(...)' to do CPU-bound work on a background thread.
Then, in a different, referenced link, http://msdn.microsoft.com/en-us/library/windows/apps/hh994635.aspx, the example it shows is as follows:
public class Example
{
// ...
private async void NextMove_Click(object sender, RoutedEventArgs e)
{
await Task.Run(() => ComputeNextMove());
// Update the UI with results
}
private async Task ComputeNextMove()
{
// ...
}
// ...
}
Here, I'll assume that ComputeNextMove
is basically a synchronous method, itself, not calling await. That then would seem to contradict the issuance of a compiler warning (unless it's a bad example...)
If I'm not calling a .net Async method at the END of my asynchronous call stack, like HttpClient.GetStringAsync
and I do want to implement some concrete "long running" synchronous logic, is there a more proper way to do it?
Perhaps my assumption is incorrect, and ComputeNextMove
could be declared as private void ComputeNextMove()
which would yield no warnings.
See Question&Answers more detail:
os 与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…