.NET的多线程库

Question

我在一些程序中使用了多个线程，但仍然感觉不太舒服。

C＃/ .NET的多线程库有哪些，哪一个优于另一个？

通过多线程库我的意思是所有有助于简化多线程编程的内容。

您定期使用什么.NET集成（例如ThreadPool）？ 你遇到了哪些问题？

Answer 1

在应用程序中使用多个线程有多种原因：

• 用户界面响应
• 并发运营
• 并行加速

人们应该选择的方法取决于你想要做什么。对于UI响应，请考虑使用BackgroundWorker，例如。

对于并发操作（例如服务器：某些 并行，但可能确实需要在单核系统上并发），请考虑使用线程池或如果任务是长期存在的并且您需要很多任务，请考虑每个任务使用一个线程。

如果您有一个所谓的令人尴尬的并行问题，可以轻松划分为小的子问题，请考虑使用从队列中提取任务的工作线程池（与CPU核心一样多的线程）。 Microsoft Task Parallel Library (TPL)可能会对此有所帮助。如果作业可以很容易地表示为monadic流计算（即在LINQ中使用转换和聚合等工作进行查询），则在TPL之上运行的并行LINQ（相同链接）可能有所帮助。

还有其他方法，例如Erlang中的Actor-style parallelism，由于缺少绿色线程模型或实现相同的方法，在.NET中难以有效实现，例如CLR支持的延续

Answer 2

我喜欢这个 http://www.codeplex.com/smartthreadpool

Answer 3

查看Power Threading库。

Answer 4

我在我的日子里编写了很多线程代码，甚至实现了我自己的线程池＆amp;调度员。这里记录了很多内容：

http://web.archive.org/web/20120708232527/http://devplanet.com/blogs/brianr/default.aspx

只是意识到我是为了非常具体的目的而编写的，并在这些条件下对它们进行了测试，并且没有真正的银弹。

Answer 5

我的建议是在移动到任何其他库之前熟悉线程池。很多框架代码都使用线程池，所以即使你碰巧找到了The Best Threads Library（TM），你仍然需要使用线程池，所以你真的需要理解它。

您还应该记住，已经在实现线程池和调优它方面做了大量工作。即将推出的.NET版本在开发并行库时引发了许多改进。

在我看来，当前线程池的许多“问题”可以通过了解它的优点和缺点来修改。

Answer 6

请记住，当你不再需要它们时，你真的应该关闭线程（或允许线程池处理），除非你很快就会再次需要它们。我说这个的原因是每个线程都需要堆栈内存（通常是1mb），所以当你有应用程序坐在线程上而不使用它们时，你就是在浪费内存。

例如，我的机器上的Outlook现在有20个线程打开并使用0％CPU。这只是浪费（至少）20mb的内存。 Word也使用另外10个线程，0％CPU。 30mb可能看起来不多，但如果每个应用程序都浪费了10-20个线程呢？

同样，如果您需要定期访问线程池，那么您不需要关闭它（创建/销毁线程会产生开销）。

Answer 7

您不必显式使用线程池，如果需要异步调用，可以使用BeginInvoke-EndInvoke。它在幕后使用线程池。见这里：http://msdn.microsoft.com/en-us/library/2e08f6yc.aspx

Answer 8

你应该看一下Concurrency & Coordination Runtime。 CCR最初可能有点令人生畏，因为它需要稍微不同的心态。这video对其工作原理有相当好的解释......

在我看来，这将是要走的路，我也听说它将使用与TPL相同的调度程序。

Answer 9

对我来说，框架的内置类绰绰有余。 Threadpool是奇怪而蹩脚的，但你可以轻松自己编写。

我经常使用BackgroundWorker类作为前端，因为它使生活变得更加容易 - 为事件处理程序自动调用。

我经常手动启动线程并在带有ManualResetEvent的字典中将它们安全起来，以便能够检查它们中的哪些已经结束。我使用WaitHandle.WaitAll()方法。问题是，WaitHandle.WaitAll不会同时加入包含超过64个WaitHandles的数组。

Answer 10

您可能希望查看有关线程模式的系列文章。现在它有实现工作线程和线程队列的示例代码。

http://devpinoy.org/blogs/jakelite/archive/tags/Threading+Patterns/default.aspx