我正在处理一个问题，我必须将很多函数调度到另一个线程，以防止当前函数阻塞。 现在我想知道执行这项任务的最快方法是什么。
目前我坚持
ThreadPool.UnsafeQueueUserWorkItem
因为它比常规的QueueUserWorkItem稍快。但是，我担心线程池可能会阻止它。有没有更快的方法调用方法调用到另一个线程？ 我只是想知道这项任务的最佳做法是什么？不安全的代码是没有问题的，因为它在已经使用了很多互操作的场景中。 谢谢 学家
答案 0 :(得分：2)
CLR（4）团队建议：
任务现在是将工作排入队列池的首选方法。
阅读CLR 4.0 ThreadPool Improvements: Part 1和New and Improved CLR 4 Thread Pool Engine了解详细信息。简而言之，原因是：本地队列，线程重用，工作窃取。 Basiclly用于负载平衡目标。
附加功能：
我不明白为什么不是答案（downvoted）。
你写了
我必须将很多功能发送给另一个线程 阻止当前函数阻止“
我回复： 一些TPL（存在于net35）'blocks'（并发集合，旋转原语等）专为高度并发访问而设计，专注于最小化或消除阻塞以提高效率工作管理。您也可以使用这些块（例如 - 阻塞问题的BlockingCollection）。 TPL设计用于以最小的开销创建和处理数百（甚至数千）个cpu / io绑定操作（任务）（或者在PLinq的帮助下数百万）。
你问：
我只是想知道这项任务的最佳做法是什么？
我已经回答：最佳做法 - TPL（推理，不仅仅是我的推荐）
答案 1 :(得分：1)
一次插入多个或更大的项目可以减少开销。
阅读您的一条评论后编辑：
我经历过类似的事情。我通常的补救措施是不立即调度每个异步请求，而是模仿Nagle's Algorithm对TCP的作用。
这里，在收到Request（）后，只有在没有异步工作待处理时才会立即发送它。如果异步工作处于挂起状态，则只有在最早的非调度请求已经过去或者已经累积了一定数量的未完成的Request（）后，才会调度一定的毫秒数。
这是一种有效的模式，可以在获得无法控制的频繁Request（）时减少开销。希望有所帮助。
答案 2 :(得分：0)
也许您可以将所有发货请求投放到列表中＆lt;＆gt;并唤醒另一个后台线程来调用QueueUserWorkItem。
我是否正确理解了这个问题？