问题 1。
使用 Parallel.For 和 Parallel.ForEach 是否更适合处理有序或无序的任务？
我问的原因是我最近更新了一个串行循环，其中 StringBuilder 用于根据各种参数生成 SQL 语句。结果是，与使用标准 foreach 循环相比，SQL 有点混乱（以至于它包含语法错误），因此我的直觉是 TPL 不适合执行数据必须出现在特定的顺序。
问题2。
TPL 是否自动使用我必须在执行之前提供任何东西的多核架构？
我提出这个问题的原因与我之前提出的一个与 TPL 操作的性能分析有关的问题有关。对这个问题的回答让我意识到，TPL 并不总是比标准串行循环更有效，因为应用程序可能无法访问多个内核，因此创建额外线程和循环的开销会导致性能下降到一个标准的串行环路。
我的直觉是 TPL 不适合执行数据必须以特定顺序出现的任务。
正确的。如果您期望事情井井有条，那么您可能会对“并行化”循环时会发生什么产生误解。
TPL 是否自动使用我必须在执行之前提供任何东西的多核架构？
请参阅 msdn 杂志上的以下文章：http: //msdn.microsoft.com/en-us/magazine/cc163340.aspx
使用该库，您可以方便地在现有顺序代码中表达潜在的并行性，其中公开的并行任务将在所有可用处理器上同时运行。
如果必须对结果进行排序，那么为了使循环并行化，您需要能够以任何顺序执行实际工作，然后对结果进行排序。这可能会或可能不会比首先按顺序执行工作更有效，具体取决于情况。如果并行化可以按任何顺序完成的工作的好处大于排序结果的成本，那么它就是净收益。如果该任务不够复杂，您的硬件不允许大量并行化，或者如果它不能很好地并行化（即，由于数据依赖性，您有很多等待时间），那么对结果进行排序可能需要更多时间时间比你从并行化循环中获得的时间要长（或者更糟糕的是，即使没有排序，并行化循环也需要更长的时间，见问题二），所以你不应该并行化它。
请注意，如果实际工作单元需要按特定顺序运行，而不是只需要按特定顺序运行结果，那么您要么无法并行化它，要么无法并行化它几乎同样有效。如果您没有正确同步对共享资源的访问，那么您实际上会得到错误的结果（就像您的情况一样）。为此，您需要记住，如果您实际上无法得出正确的结果，那么性能优化将毫无意义。
使用 TPL，您真的不需要太担心您的硬件。您无需显式添加或限制任务。虽然有几种方法可以做到，但几乎任何时候你做这样的事情都会损害性能。当你做这样的事情时，你是在给 TPL添加限制，所以它不能做它想做的事。通常它比你更清楚。
您还谈到了这里的另一点，那就是并行化循环通常需要更长的时间（您只是没有给出导致这种行为的可能原因）。通常需要完成的实际工作非常小，以至于创建线程、管理线程、处理上下文转换和根据需要同步数据的工作可能比并行工作所获得的工作要多。这就是为什么在决定并行化某些工作以确保它真正从中受益时实际进行大量测试很重要的原因。
在第 1 点，如果使用 TPL，您不知道哪个任务运行的顺序。这就是并行与顺序的美妙之处。有一些方法可以控制事物的顺序，但是你可能会失去并行的好处。
On 2：TPL 使用开箱即用的多核。但是使用多个线程确实总是有开销。调度程序的负载增加，线程（上下文）切换不是免费的。为了保持数据同步以避免竞争条件，您可能需要一些锁定机制，这也会增加开销。
使用 TPL 制作快速并行算法变得容易得多，但仍然是某种艺术。
对于无序列表来说，这并没有好坏之分-您在 #1 中的问题是您对 a 有共享依赖关系，这就是并行查询失败的原因。TPL 在独立的工作单元上表现出色。即使这样，您也可以使用一些简单的技巧来强制评估并行查询，并在并行操作全部完成后保持结果的原始顺序。StringBuilder
TPL 和 PLINQ 在技术上是截然不同的东西。PLINQ 使用 TPL 来实现它的目标。也就是说，PLINQ 尝试检查您的体系结构并尽其所能构建集合的执行。TPL 只是任务架构的包装器。由您决定创建任务的开销（类似于 1MB 内存）以及执行任务的上下文切换开销是否大于简单地串行运行任务。
显然，TPL 不是构建像查询这样的有序集的好工具。
如果您有一系列任务要对一组项目执行，那么您可以使用 BlockingCollection。这些任务可以并行执行，但保持集合的顺序。