使用Task.Wait而不是等待异步编程 [英] Using Task.Wait instead of await for async programming
问题描述
.net关于Tasks的文章显示了以下两个代码片段，一个使用await，另一个使用Task.Wait，并说两者在功能上是等效的.
The .Net article on Tasks shows two following two code snippets, one using await and the other using Task.Wait and says both are "functionally equivalent".
那在技术上是不是不正确?有人可以澄清一下吗?
Isn't that technically incorrect then? Can someone please clarify?
如果任务被认为是异步的并且构成了异步编程(TPL)的基础，为什么ASP.Net仍然允许对其进行同步等待?那样违反他们的主要用途吗?
Also if Tasks are supposed to be asynchronous and form the basis for Asynchronous Programming (TPL), why would ASP.Net allow a synchronous Wait on them anyway? Doesn't that kind of violate their main utility?
using System;
using System.Threading.Tasks;
public class Example
{
public static async Task Main()
{
await Task.Run( () => {
// Just loop.
int ctr = 0;
for (ctr = 0; ctr <= 1000000; ctr++)
{}
Console.WriteLine("Finished {0} loop iterations",
ctr);
} );
}
}
// The example displays the following output:
// Finished 1000001 loop iterations
using System;
using System.Threading.Tasks;
public class Example
{
public static void Main()
{
Task t = Task.Factory.StartNew( () => {
// Just loop.
int ctr = 0;
for (ctr = 0; ctr <= 1000000; ctr++)
{}
Console.WriteLine("Finished {0} loop iterations",
ctr);
} );
t.Wait();
}
}
// The example displays the following output:
// Finished 1000001 loop iterations
本文应该清楚地说明这两个调用之间的区别.
The article should explain the differences between the two calls clearly.
推荐答案
那么，从技术上来说这不是正确的吗?
Isn't that technically incorrect then?
否，因为它是非常特定的.并不是说编写等待任务的async方法总是与同步等待该任务相同，而是 only ，它专门指代一个任务的情况. async Main方法作为应用程序的入口点.当您使Main方法async时，它仅同步等待返回的任务，使其在功能上等效于仅同步地等待该方法内部的任务，而不是仅使方法async 确切情况.
No, because it's being very specific. It's not saying that writing an async method that awaits a task is always the same as just synchronously waiting on that task, it's only referring to very specifically the case of an async Main method as an entry point for the application. When you make the Main method async, it just synchronously waits on the returned task, making it functionally equivalent to just synchronously waiting on the task inside the method instead of making the method async only in that one exact situation.
(您也可以提出一个论点，那就是说具有提供的参数的StartNew和Run是等效的，并且无意引用异步方法与同步等待方法之间的区别. )
(You could also make an argument that's it's just trying to say that StartNew with the parameters provided and Run are equivalent, and isn't intending to refer to the difference between the method being async versus synchronously waiting.)
为什么ASP.Net仍然允许同步等待它们?
why would ASP.Net allow a synchronous Wait on them anyway?
并非专门创建
Task来表示异步完成的工作.它旨在做到这一点，并且还可以使用多个线程并行并行地工作.使用异步任务时，基本上应该永远不要使用Wait或其他同步阻塞机制，但是如果使用它来同步执行多线程工作，则很有用.您可以提出一个[良好]的论点，即他们应该将这些概念分开，但事实并非如此，现在更改它为时已晚.
Task wasn't created exclusively to be a representation of work done asynchronously. It was designed to do that and also to synchronously work in parallel using multiple threads. When you're using tasks for asynchrony, you should basically never be using Wait or other synchronous blocking mechanism, but if you're using it to do multithreaded work synchronously, it's useful. You could make a [good] argument that they should have kept those concepts separate, but they didn't, and it's way too late to change it now.
那不是违反他们的主要实用工具吗?
Doesn't that kind of violate their main utility?
是的，是的.这就是为什么我不喜欢这种实现方式的原因，并且希望他们以不同的方式实现它.但是他们没有.
Yes, yes it does. Which is why I'm not a fan of this implementation, and would have preferred they'd implemented it differently. But they didn't.
本文应该清楚地说明这两个调用之间的区别.
The article should explain the differences between the two calls clearly.
是的.
这篇关于使用Task.Wait而不是等待异步编程的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
