在.net中开发多线程应用程序和并行编程有什么不同?

我认为"多线程"就像术语所说的那样:使用多个线程。

"并行处理"是:将一组工作拆分到多个线程中，以便工作可以并行处理。

这是否意味着多核和并行编程应用程序不可能使用以前的。net版本?

一点也不。你可以用Thread类来做。写起来要困难得多，而且要写对要困难得多。

在。net多线程应用程序中，我是否可以控制多核/并行使用/内核之间的分布?

没有，但是你不需要这样做。你可以在应用程序的处理器亲和性上乱搞，但在。net级别，这几乎不是一个成功的策略。

任务并行库包含一个"分区器"概念，可以用来控制工作的分布，这是控制线程在内核上的分布的更好解决方案。

如何确定一个线程要运行的内核，并将线程属性为特定的内核?

你不应该这样做。.NET线程不一定对应于操作系统线程;你处在一个更高的抽象层次。现在，默认的。net主机确实将线程一对一地映射，所以如果您希望依赖于未记录的实现细节，那么您可以通过抽象并使用P/invoke来确定/驱动处理器关联。但是如上所述，它是没有用的。

.NET 4.0+任务并行库启用了哪些在以前的。net版本中不可能实现的功能?

。但它确实使并行处理(和多线程)变得更容易了!

你能给我提示如何具体创建并行代码在pre-。NET4(在.NET3.5)，考虑到我熟悉多线程开发?

首先，没有理由为这个平台开发。没有。net 4.5已经发布了，最后一个版本(。. NET 4.0)支持下一个旧版本的所有操作系统(。

但是如果你真的想，你可以通过旋转Thread对象或BackgroundWorker对象来做简单的并行处理，或者通过将工作直接排队到线程池。所有这些方法都比TPL中的Task类型需要更多的代码(特别是在错误处理方面)。

如果我问你"你用自己开发的语言编写商业软件吗? "你自己挖井喝水吗?"

这就是通过创建线程并管理它们来编写多线程的区别，而您可以使用TPL对线程进行抽象。多核和线程调度是在操作系统上维护的，所以你不需要担心你的线程是否在你的系统支持的核心上执行。

查看这篇文章，它基本上总结了在TPL之前(实际上)不可能的事情，即使许多公司已经酝酿了自己的并行处理库，但它们都没有被充分优化以利用流行架构的所有资源(仅仅因为这是一项大任务& &;微软有很多资源+他们很好)。另外值得注意的是英特尔的对等实现TBB vs TPL

这是否意味着多核和并行编程应用程序不可能使用以前的。net版本?

一点也不。Thread和ThreadPool用于调度其他线程上的计算，ManualResetEvent用于同步，这些类型从。net 1开始就出现了。

在。net多线程应用程序中，我是否可以控制多核/并行使用/内核之间的分布?

不，这主要是操作系统的工作。您可以设置ProcessThread的ProcessorAffinity，但是没有简单的方法从Thread获得ProcessThread(因为最初认为。net Thread可能不直接对应于操作系统线程)。通常没有理由这样做，尤其不应该为ThreadPool线程这样做。

.NET 4.0+任务并行库启用了哪些在以前的。net版本中不可能实现的功能?

我得说它没有让任何不可能的事情成为可能。但它使许多任务变得更简单。

您总是可以编写自己版本的ThreadPool，并手动使用同步原语(如ManualResetEvent)在线程之间进行同步。但是正确而有效地做这些是很容易出错的工作。

在。net中开发多线程应用程序和并行编程有什么不同?

这只是一个命名的问题，与你之前的问题没有太大关系。并行编程意味着同时执行多个操作，但它并没有说明如何实现并行性。为此，您可以使用多台计算机，或多个进程或多个线程，甚至单个线程。

(单线程并行编程可以工作，如果操作不是cpu限制，如从磁盘读取文件或从互联网获取一些数据。)

所以，多线程编程是并行编程的一个子集，尽管它最常用于。net。

多线程过去只能在单核cpu上使用。我相信在。net的世界里，"并行编程"代表了编译器/语言，以及命名空间和"库"的添加，它们促进了多核功能(比以前更好)。从这个意义上说，"并行编程"是多线程下的一个类别，它提供了对多个cpu/内核的改进支持。

我自己的思考:与此同时，我认为。net"并行编程"不仅包含多线程，还包含其他技术。考虑到新的async/await工具不能保证多线程，因为在某些情况下，它们只是延续传递样式的抽象，可以在单个线程上完成所有操作。从这个意义上讲，包括运行不同进程(可能在不同机器上)所产生的混合并行性，多线程只是更广泛的"并行编程"概念的一部分。

但是如果你考虑到。net版本，我认为前者是一个更好的解释。