是否可以一起使用线程并发和并行？

Question

对于我的一个项目，那种内容聚合器我想引入并发性和可能的​​并行性。这可能看起来毫无意义，因为并发性和并行性采用不同的方法。 （并行通过线程引入了即时并发，而并行性提供了潜力）。

为了更好地解释我的问题，让我总结一下我的问题集。

由于我的项目是内容聚合器（聚合提要，播客和类似内容），它基本上从Web读取数据，解析它们以返回有意义的数据。

到目前为止，我采用了一种非常简单的顺序方法。假设我们需要解析一些Feed。

foreach(feed in feeds)
{
   read_from_web(feed)
   parse(feed)
}

因此，使用顺序方法解析所有提要并处理它们在很大程度上不仅取决于解析器代码，还取决于从Web获取xml源所需的时间。我们都知道，从网络上读取源代码可能需要不同的时间（因为网络条件和类似问题）。

因此，为了加快代码，我可以采用工作线程的方法，这将引入立即并发;

因此，定义数量的工作线程可以接受一个feed＆amp;同时解析（这肯定会加快整个过程 - 因为我们会看到通过网络等待数据的影响较小）。

这一切都没关系，直到我的项目目标受众主要运行多核cpu - 因为他们是游戏玩家 - 。

我想在处理内容时也使用这些内核，因此开始阅读潜在的并行性http://oreilly.com/catalog/0790145310262。我还没有读完它，也不知道这是否已经讨论过了，但我对此非常着迷，并想通过stackoverflow来了解整体想法。

因为本书描述了潜在的并行性：潜在的并行性意味着你的程序被编写为当并行硬件可用时运行得更快 并且大致相同作为等效的顺序程序，当它不是时。

所以真正的问题是，虽然我使用工作线程进行并发，但我仍然可以使用可能的并行性吗？ （在工作线程上运行我的feed解析器并仍然将它们分发到cpu核心 - 如果cpu当然支持多核的话）

Answer 1

我认为考虑IO绑定工作和CPU限制工作更有用;线程可以帮助两者。

对于IO绑定工作，您可能正在等待外部资源（在您的情况下，要读取的源）。如果你必须等待多个外部资源，那么只有并行等待它们才有意义，而不是一个接一个地等待它们。最好通过旋转阻塞IO的线程来完成。

对于受CPU限制的工作，您希望使用所有核心来最大化完成该工作的吞吐量。要做到这一点，您应该创建一个工作线程池，其大小与您的内核数量大致相同，并分解和分配工作。 [你如何分解和分配作品本身就是一个有趣的问题。]

在实践中，我发现大多数应用程序都存在这两个问题，使用线程解决这两种问题是有意义的。

Answer 2

好吧，似乎我被关于可能的并行性的书籍描述误解了。感谢答案，我能够弄清楚事情;

来自msdn：http://msdn.microsoft.com/en-us/library/dd460717(VS.100).aspx

  

任务并行库（TPL）是一个   一组公共类型和API   System.Threading和   System.Threading.Tasks中的命名空间   .NET Framework版本4.   TPL的目的是制作   开发人员提高效率   简化添加过程   并行性和并发性   应用。 TPL扩展了   动态并发度   最有效地使用所有   可用的处理器。在   此外，TPL处理   划分工作，   调度线程   ThreadPool，取消支持，   国家管理等低级别   细节。通过使用TPL，您可以   最大化代码的性能   同时专注于你的工作   程序旨在完成。

所以基本上它意味着TPL可以通过线程处理并发的所有细节，并且还支持多核上的并行性。