【问题标题】:Is there any point to using Task Parallel Library使用任务并行库有什么意义吗
【发布时间】:2015-07-13 10:49:55
【问题描述】:

我有一台四核电脑。

我曾考虑使用任务并行库以编程方式实现多核处理。但是,当我在 Google 上搜索示例时,我被告知 CPU 会自动处理这个问题,最好不要管它。

现在,我在 Code Project 上找到了另一篇赞美这个库的文章。

使用这个库有什么好处吗?

谢谢

【问题讨论】:

  • 操作系统不会为您分配工作。如果要在多个内核上工作,则必须对每个工作单元进行分区和调度。这就是Task Parallel Library 为您所做的。操作系统将在可用 CPU 上安排工作。
  • 嗨,但是如果我使用线程,这不会自动为我使用圆顶吗?
  • TPL 为您提供了对 Thread 类的抽象,这是 .NET 中可用的最低包装机制。它为您省去了自己创建并行性的麻烦。查看Parallel.ForEachParallel.For。另外,请查看PLINQ
  • 多个线程将自动“计划”在可用处理器上。这个库只是让你更容易使用线程。
  • 如果 OP 是初学者或者问题不是那么聪明,并不意味着这是一个值得否决的坏问题。海事组织

标签: c# task-parallel-library


【解决方案1】:

除非您的应用程序正在积极利用并行处理,否则操作系统和 CPU 都不会自动为您执行此操作。操作系统和 CPU 可能会在多个内核之间切换应用程序的执行,但这不会使其在不同内核上同时执行。为此,您需要使您的应用程序能够至少并行执行部分。

根据MSDN Parallel Processing and Concurrency in the .NET Framework 在.NET 中进行并行处理基本上有三种方式:

  1. 您自己处理线程及其同步的托管线程。
  2. 各种异步编程模式。
  3. .NET Framework 中的并行编程,Task Parallel LibraryPLINQ 都是其中的一部分。

使用 TPL 的原因包括它和 MSDN 文章中的随附工具

简化并行开发,以便您可以用自然的习惯编写高效、细粒度和可扩展的并行代码,而无需直接使用线程或线程池。

Threads vs. Tasks 有助于在线程和 TPL 之间做出决定 结论:

最重要的是,Task 几乎总是最好的选择;它提供了更强大的 API 并避免浪费操作系统线程。

在现代代码中显式创建自己的线程的唯一原因是设置每个线程的选项,或者维护一个需要维护自己的身份的持久线程。

【讨论】:

  • 嗨,是的。这就是我的想法,我应该更好地表达我最初的问题。我应该添加“不会线程化”为我完成这项工作?
  • 当然。然而,使用任务并行库通常比使用线程更容易。
  • @AndrewSimpson,使用线程作为最后的手段,除非您有一些必须在应用程序的整个生命周期中并行发生的功能。 TPL、async/await 和任务都比线程更易于使用。
  • @DavidArno 谢谢并理解。我将坚持为我的相机流使用线程,它们只需要创建一次。但是,对于我的 Task.Runs 东西,我可以切换到 TPL ..
  • 我没有对你投反对票。我发现你的回答很有用:)
【解决方案2】:

任务并行库通过Task Schedulers 执行其操作。您可以将您的 TPL 配置为它使用的调度程序。您可以编写自定义任务调度程序,它可以为一项任务创建一个线程。这样,您可以在管理线程方面拥有配置优势。类似于使用依赖注入框架优于 DIY-DI 的优势。

并且已经有很多 SO 条目用于区分任务和线程

  1. Task vs Thread
  2. Task vs Thread
  3. Multithreading or TPL

【讨论】:

  • 您好,感谢您提供这些链接。虽然他们解释了使用 Threads v TPL 的不同方式,但并没有说明它是否更有效。我能看到使用它的唯一方法来自@Yuval Itzchakov 的评论。
  • 我认为它提到了 TPL 对线程的有效性。你如何衡量效率取决于你-:)
  • 好吧,我将保持客观并阅读所有这些链接 - 谢谢
猜你喜欢
  • 2017-03-30
  • 2017-07-12
  • 2011-03-03
  • 2016-09-16
  • 2010-09-23
  • 1970-01-01
  • 2012-07-08
  • 2015-01-14
  • 2018-08-13
相关资源
最近更新 更多