await/async 与自定义线程的用法（和优点）答案

【问题标题】：Usage (and advantages) of await/async with custom threadsawait/async 与自定义线程的用法（和优点）
【发布时间】：2014-05-26 05:13:55
【问题描述】：

我正在编写一些代码来执行一些网络请求、处理答案并将结果返回给调用者。在我看来，异步/等待的自然背景。这是我写的方法：

protected async Task<ProcessingResult> ProcessWebPagesAsync(/* args */)
{
    // awaits and other code here
}

调用者在专门为运行这些请求而创建的线程上运行，我目前无法更改实现。我的问题是：

在不是来自线程池的线程上使用 async/await 是否有优势？
如何从现有代码的上下文中调用我的根方法？（见示例）

public class MyProcessor : ProcessorBase
{
    public override ProcessingResult ProcessWebPages(/* args */)
    {
        return this.ProcessWebPagesAsync(/* args */).Result;
    }

    protected async Task<ProcessingResult> ProcessWebPages(/* args */)
    {
        // awaits and other code here
    }
}

因此，ProcessorBase.ProcessWebPages() 在“专用”线程上被调用。在这里使用 async/await 真的有意义吗？我有福利吗？

【问题讨论】：

标签： c# .net multithreading asynchronous async-await

【解决方案1】：

将async/await 与I/O 绑定操作一起使用的好处是，您可以避免分配专用Thread 的成本，这将主要阻止等待从网络硬件返回的响应。当您await 时，正在处理工作并在响应返回时通过 IOCP 池回调，您可以设置您希望其余方法（继续）在何处运行（线程池线程、UI 线程等） ..)

我认为在专用线程上运行 ProcessorBase.ProcessWebPages 并没有什么特别的好处。如果可以的话，你应该避免为你的工作分配这样的线程，而是使用纯async。我还建议坚持异步方法命名的约定并将您的方法名称更改为ProcessorBase.ProcessWebPagesAsync

【讨论】：