我应该使用 Task.Run 在同步上下文中等待任务吗？

Question

我有一个无法转换的 ASPX 页面，async但它async在同步上下文中使用了一些方法。它调用它们的方式是这样的：

public void MySyncMethod()
{
    var myTask = Task.Run(() => _myField.DoSomethingAsync());
    myTask.Wait();
    //use myTask.Result
}

就async/await和/或阻塞而言，这样做与以下有什么区别吗？

public void MySyncMethod()
{
    var myTask = _myField.DoSomethingAsync(); //just get the Task direct, no Task.Run
    myTask.Wait();
    //use myTask.Result
}

我假设以前的开发人员Task.Run出于某种原因添加了。但是HttpContext当工作在不同的线程上运行时，我遇到了访问事物的问题。

有理由在Task.Run这里使用吗？

Answer 1

就异步/等待和/或阻塞而言，这样做与以下有什么区别吗？

是的，第一个代码块使用线程池线程然后等待它返回，因此您使用两个线程而不是一个。他们俩都挡住了。

我假设以前的开发人员出于某种原因添加了 Task.Run。

是的，（直接）阻塞async来自 ASP.Net 上下文的代码是一个坏主意，可能会导致死锁。因此，您的第二个代码块更有效（在线程使用中），但会遇到严重的死锁问题。

这里的正确解决方案是使public void MySyncMethod() async自己 ( public async Task MySyncMethod())。这两种解决方案都有缺点，唯一真正的出路是创建整个调用堆栈async。如果你能做到这一点，那就去做吧。

如果你不能async从另一个async方法调用一个方法，那么Task.Run就是要走的路。请参阅如何从 C# 中的同步方法调用异步方法？更多细节。

如果你想HttpContext在你的线程中阅读在异步任务中使用 HttpContext我肯定会赞成：

• 做好每一件事 async
• 或者从上下文中读取值然后传递它们

这些答案的选项并记住

首先，您不是在创建对象的副本，而只是复制对对象的引用。HttpContext不是 struct……等