逻辑线程与物理线程

Question

我正在阅读此链接http://msdn.microsoft.com/en-us/library/ms750441.aspx

上的System.Threading.DispatcherObject类型

文章提到了逻辑和物理线程之间的一对一关系。以下是文章的片段：

  

在WPF的设计阶段，目标是转向单一   执行线程，但是非线程“关联”模型。线   当组件使用执行的标识时，就会发生关联   线程存储某种类型的状态。最常见的形式是   使用线程本地存储（TLS）来存储状态。 线程亲和力   要求每个逻辑执行线程只由一个拥有   操作系统中的物理线程，它可以成为内存   密集

有人可以。解释逻辑与物理线程之间的区别是什么？

Answer 1

本地线程是运行时中的线程。这个线程比完整的物理线程更轻，适用于重量较轻的过程。物理线程是处理器上下文切换到并处理的线程。随着操作系统跟踪它，它有更多与之关联的元数据。涉及的细节更多，但这是一个快速概述。

在这种情况下，物理线程将在内部包含这些逻辑“虚拟线程”。

Answer 2

.NET 2.0的CLR确实计划使用fiber support as .NET Thread for SQL CLR。它从来没有进入产品，但可能是在遥远的未来，CLR将支持它。因此这个大红线亲和力警告。

本地使用OS does support光纤，但由于您在用户模式下切换堆栈以使其他代码在同一物理线程上运行，因此它们很难正确使用。这确实消除了在某些高性能场景中有意义的昂贵的上下文切换。使用光纤作为抽象几乎不是一个好主意，因为你不能调用任何第三方库，因为你不知道api是否承担线程亲和力。

当今多核计算机中的上下文切换成本远低于之前的几个Windows版本和处理器。我怀疑在现实世界的应用程序中你会获得很多光纤。除此之外，芯片制造商正在努力使上下文切换的成本更低。有designs discussed使它像一个CPU周期一样便宜。

简而言之：

如果您自己托管CLR并使用CLR托管API的尚未（现有）功能，则可能发生CLR Thread对象不是物理OS线程。

据我所知，即使在Windows 8中，Window消息泵系统也会停留在那里，其中每个窗口都与创建线程具有线程亲和性，该线程也必须抽取窗口消息。