异步执行方法的最快方法？答案

【问题标题】：Fastest way to asynchronously execute a method?异步执行方法的最快方法？
【发布时间】：2010-08-03 07:08:15
【问题描述】：

我目前正在处理一个问题，我必须将大量函数调度到另一个线程以防止当前函数阻塞。现在我想知道执行此任务的最快方法是什么。

目前我被困住了

ThreadPool.UnsafeQueueUserWorkItem

因为它比常规的 QueueUserWorkItem 稍快。但是，我担心线程池可能会在这里阻塞。是否有更快的方法将方法调用分派到另一个线程？我只是想知道这样一项任务的最佳做法是什么？不安全的代码不会有问题，因为它在已经使用了很多互操作的场景中。谢谢 j.

【问题讨论】：

当您说“更快”时，您的意思是要减少“主”线程上的阻塞吗？具体来说，将项目排队等待后台处理的调用是否尽快返回？
WRT 您声明的关注点，线程池不会阻塞该调用（或正常的“安全”调用），但它确实返回一个布尔值，说明它是否成功排队，理论上是如果它返回 false，你可能想在当前线程上执行它，或者稍后再试，或者其他什么。
您每次都派发到同一个方法吗？他们需要彼此异步操作吗？生产者/消费者方法是否可以接受？（所以调用者只是将一些东西添加到队列中）。这是哪个版本的 .NET？
是的，我希望“调度”线程尽快返回。如果调度的方法调用的实际执行延迟了一些毫秒，我不在乎。它只是关于快速返回时间，到目前为止，unsafequeueuserworkitem 是最快的。还是有另一种方法可以将数百个小工作部分分派到另一个线程，同时在调用线程中快速返回？
我收到很多针对特定对象的 Request()-调用（每秒几百个）并异步返回这些生成时间稍长的对象（可以并行化）（分布在 20-30同一类的实例）。但是，调用这些 Request() 方法的方法需要它们快速返回，否则会破坏整个处理过程。无法更改 Request() 调用代码。

标签： c# performance multithreading asynchronous

【解决方案1】：

CLR(4) 团队推荐：

任务现在是将工作排队到线程池的首选方式。

阅读CLR 4.0 ThreadPool Improvements: Part 1 和New and Improved CLR 4 Thread Pool Engine 了解详细信息。简而言之，原因是：本地队列、线程重用、工作窃取。基本上是为了负载均衡目标。

附加：

我不明白为什么这不是答案（否决）。

你写的

我必须将大量的函数调度到另一个线程来防止当前函数阻塞”

我回复：一些 TPL（针对 net35 存在）“块”（并发集合、旋转原语等）专为高并发访问而设计，专注于最小化或消除阻塞以提高效率工作的管理。您也可以使用这些块（例如 - BlockingCollection 解决您的问题）。 TPL 旨在以最小的开销（或借助 PLinq 的帮助下的数百万）创建和处理数百个（甚至数千个）cpu/io-bound 操作（任务）。

你问：

我只是想知道这种任务的最佳做法是什么？

我已经回答了：最佳实践 - TPL（合理，不仅仅是我的建议）

【讨论】：

+额外。如果不赞成，请添加 cmets

【解决方案2】：

一次插入多个或更大的项目应该会减少开销。

在阅读您的一个 cmets 后编辑：

我也经历过类似的事情。我通常的补救措施不是立即分派每个异步请求，而是模仿Nagle's Algorithm 对 TCP 所做的事情。

这里，在收到 Request() 后，只有在没有异步工作挂起时，您才会立即调度它。如果异步工作处于待处理状态，则只有在自最早的未调度请求已过去一定毫秒数或累积一定数量的未完成 Request() 后，您才会调度。

当频繁收到您无法控制的 Request() 时，这是一种减少开销的有效模式。希望对您有所帮助。

【讨论】：

这难道不会违背 OP 的前提，即意图非常快速地调度。消费者的执行与生产者无关。在这种情况下，Nagle 的缓冲类型可能没有帮助，不是吗？
“发送速度非常快”是模棱两可的。 Nagle 算法确保相当低的调度延迟和非常好的吞吐量。这就是我所说的快速调度，尽管让我们听听 OP。

【解决方案3】：

也许您可以将所有调度请求放入 List 并唤醒另一个后台线程来调用 QueueUserWorkItem。

我是否正确理解了这个问题？

【讨论】：