1

我目前正在阅读专业版。NET 4.0 Parallel Programming in C#，但每章末尾没有练习。虽然我理解了这个概念，但我仍然觉得缺乏一些实际的实践。我需要一些真正的问题来巩固我学到的东西。我在互联网上搜索，但主要是教程......
是否有仅针对 TPL 的问题集？我发现这个库在很多方面都很吸引人，我只是想把它弄好。所以我想知道是否有人可以分享我在 TPL 领域的一些问题，以便我可以练习我的知识。您遇到的任何问题或参考将不胜感激。我只需要问题，我会自己找到解决方案。提前致谢。

4

3 回答 3

2

在我看来，TPL 完全是关于可扩展性的。如果这样想，你会找到在你的代码中使用它的方法。如果它不是并行完成的 - 它是按顺序完成的。在一个动作很少的小型应用程序中 - 顺序处理很棒。但是，当您对特定流程有数千个请求时 - 这就是 TPL 的用武之地。

假设您要处理请求列表。在请求中是一个网站的 url。该过程是下载 HTML 内容并从页面中提取特定数据并将其存储在数据库中。通常这必须按顺序进行。现在想象一下 10 个人同时执行这个请求。最后按下提交按钮的人将不得不等到他之前的所有其他人完成处理。这可能需要很长时间并且无限期地增加。

视觉表现：

[Request01] - Finished 
[Request02] - Started
[Request03] - Waiting
[Request04] - Waiting
[Request05] - Waiting
[Request06] - Waiting
[Request07] - Waiting
[Request08] - Waiting
[Request09] - Waiting
[Request10] - Waiting

使用 TPL - 您可以将这些请求存储在并发集合（TPL 集合）中并并行迭代集合。TPL 不仅将这些请求拆分为线程并同时运行它们，它还在处理器上的每个内核上执行此操作。

假设您有一台带有两个双核处理器的服务器；这个过程看起来像这样：

CPU1 Core1
  [Request01] - Finished 
  [Request02] - Started
  [Request03] - Started

CPU1 Core2
  [Request04] - Finished 
  [Request05] - Started
  [Request06] - Started

CPU2 Core1
  [Request07] - Finished 
  [Request08] - Started
  [Request09] - Started

CPU2 Core2
  [Request10] - Finished

如您所见 - 这可以提高产量并减少等待时间。TPL 的好处——如果你能开发一个健全的应用程序，那么可扩展性就会从软件回到硬件上——这很棒。您对这项服务的受众越多，您投入的服务器就越多。在 IT 世界中 - 这更容易接受。每个人都愿意扩大他们的硬件；没有人愿意更新他们的软件。

我希望这有助于为您指明正确的方向！

于 2012-05-27T13:46:28.917 回答
1

我不认为有特殊的问题集只能用 TPL 来解决。

TPL 的目的是通过简化向应用程序添加并行性和并发性的过程来提高开发人员的工作效率。TPL 动态扩展并发程度，以最有效地使用所有可用的处理器。通过使用 TPL，您可以最大限度地提高代码的性能，同时专注于您的程序旨在完成的工作

这是来自 msdn 的 TPL 的描述/目的，我认为它总结得很好；
我认为您所问的关于 tpl 的问题通常可以被问及多线程，我不确定是否总是很容易判断多线程是否是性能方面的最佳解决方案（除了非常明显的情况，当您的代码需要访问独立的数据源，或类似的东西）。当您决定多线程是解决问题的最佳解决方案时，没有自动方法可以告诉您使用多少线程以及如何在它们之间分配工作。
假设您有一个应用程序必须通过某些 Web 服务发送 X 封电子邮件。你会在一个大循环中发送所有 X 吗？您会将它们分成单独的 N 个线程并在每个线程中发送 X/N 吗？这些问题有时只能通过试验和性能分析监控来回答，据我所知，TPL 库旨在为您解决这个问题：而不是期望您进行所有这些计算（这也可能无法让您获得每次执行的结果相同），tpl 旨在为您动态计算所需的并行度级别，因此，至少在理论上，在每种情况下提供最佳性能。

于 2012-05-26T09:26:37.300 回答
1

我曾多次与 TPL 合作，发现它非常有帮助。根据我的经验，我遇到了以下挑战：

  1. 我正在开发一个在线支付系统。从理论上讲，每秒可能有数百到数千笔付款。对于每次付款，我都必须调用 Web 服务来通知服务提供商有人支付了 n 金额。因为调用服务是一个 IO 操作，所以从站点本身调用服务是没有问题的，因为我们很快就会用完池中的线程。这就是我决定使用作业调度程序的原因。该作业定期运行并从数据库中获取待处理的付款（交易），这就是 TPL 大放异彩的地方。一个接一个地发送数百或数千个呼叫服务是非常无用的。这就是我使用 TPL 的原因。它自动分配最佳数量的线程并并行调用适当的服务。正如我所说，因为 web 服务调用是一个 IO 操作，
  2. 另一个问题是，当您需要处理不发生 IO 操作的大量数据（例如可以表示为集合数组）时，一切都是 CPU 绑定的。您可以使用 TPL 将负载分配到多个 CPU/核心。在这种情况下，每个 cpu 核心最好有 1 个线程。
于 2012-05-26T11:18:23.253 回答