.NET的multithreading库
我在一些程序中使用了多个线程，但仍然感觉不太舒服。
C＃/ .NET的multithreading库有哪些，哪一个优于另一个？
通过multithreading库我的意思是所有有助于使multithreading编程更容易的东西。
你定期使用什么.NET集成（比如ThreadPool）？ 你遇到了哪些问题？
在应用程序中使用多个线程有多种原因：
- UI响应
- 并发操作
- 并行加速
应该选择的方法取决于你想要做什么。 对于UI响应，请考虑使用BackgroundWorker 。
对于并发操作（例如服务器：不必是并行的，但可能确实需要在单核系统上并发），考虑使用线程池，或者，如果任务是长寿的，那么你需要很多，考虑每个任务使用一个线程。
如果你有一个所谓的令人尴尬的并行问题，可以轻松划分为小的子问题，可以考虑使用工作线程池（与CPU核心一样多的线程）从队列中提取任务。 Microsoft 任务并行库（TPL）可能会有所帮助。 如果作业可以很容易地表示为monadic流计算（即在LINQ中使用转换和聚合等工作进行查询），则在TPL之上运行的并行LINQ（相同链接）可能会有所帮助。
还有其他方法，例如在Erlang中看到的Actor风格的并行性，由于缺少绿色线程模型或实现相同的方法（例如CLR支持的延续），因此在.NET中难以有效实现。
我喜欢这个http://www.codeplex.com/smartthreadpool
查看Power Threading库。
我在我的日子里编写了很multithreading代码，甚至实现了我自己的线程池和调度程序。 这里记录了很多内容：
http://web.archive.org/web/20120708232527/http://devplanet.com/blogs/brianr/default.aspx
只是意识到我为了非常具体的目的编写了这些，并在这些条件下测试它们，并且没有真正的银弹。
我的建议是在移动到任何其他库之前熟悉线程池。 很多框架代码都使用线程池，所以即使你碰巧找到了The Best Threads Library（TM），你仍然需要使用线程池，所以你真的需要理解它。
您还应该记住，已经为实现线程池和调整它做了很多工作。 即将推出的.NET版本在开发并行库时引发了许多改进。
在我看来，当前线程池的许多“问题”可以通过了解它的优点和缺点来修改。
请记住，当你不再需要它们时，你应该关闭线程（或允许线程池处理），除非你很快就会再次需要它们。 我说这个的原因是每个线程都需要堆栈内存（通常是1mb），所以当你让应用程序坐在线程上但不使用它们时，你就是在浪费内存。
例如，我的机器上的Outlook现在有20个线程打开并使用0％CPU。 这简直浪费了（至少）20mb的内存。 Word也使用另外10个线程，0％CPU。 30mb可能看起来不多，但如果每个应用程序浪费10-20个线程怎么办？
同样，如果您需要定期访问线程池，则无需关闭它（创建/销毁线程会产生开销）。
您不必显式使用线程池，如果需要异步调用，可以使用BeginInvoke-EndInvoke。 它在幕后使用线程池。 请参阅此处： http ： //msdn.microsoft.com/en-us/library/2e08f6yc.aspx
您应该查看并发和协调运行时 。 CCR起初可能有点令人生畏，因为它需要稍微不同的心态。 该video对其工作原理进行了相当好的解释……
在我看来，这将是要走的路，我也听说它将使用与TPL相同的调度程序。
对我来说，框架的内置类绰绰有余。 Threadpool是奇怪而蹩脚的，但你可以轻松编写自己的。
我经常使用BackgroundWorker类作为Frontends，因为它使生活变得更加容易 – 为事件处理程序自动调用。
我经常手动启动线程并使用ManualResetEvent将它们安全地保存在字典中，以便能够检查它们中的哪些已经结束。 我使用WaitHandle.WaitAll()方法。 问题是，WaitHandle.WaitAll不会同时加入包含超过64个WaitHandles的数组。
您可能希望查看有关线程模式的系列文章。 现在它有实现WorkerThread和ThreadedQueue的示例代码。
http://devpinoy.org/blogs/jakelite/archive/tags/Threading+Patterns/default.aspx