-
Are。NET线程是轻量级用户模式线程还是内核模式操作系统线程？
-
此外，在保留SQL Server的情况下，在之间是否存在一对一的对应关系。NET线程是操作系统线程吗？
我也很感兴趣，因为Thread类有一对名为BeginThreadAffinity和EndThreadAffinity的对称方法，其文档巧妙地表明了这一点。NET线程是对真实操作系统线程的轻量级抽象。
此外，我不久前在某个堆栈溢出线程上读到，微软像SQL Server一样，试图在CLR中保持这种分离。我记得，有一些项目正在进行中，将Fiber API用于此目的，但我不能说我理解我阅读的所有细节。
我想要一些关于这个主题的更详细的文献，比如a的内部结构。NET线程相对于Windows创建的线程。虽然有很多关于Windows创建的线程结构的信息，Jeffrey Richter的《高级Windows编程》一书就是其中之一，例如，我找不到任何专门讨论线程内部结构的文献。NET线程。
有人可能会争辩说，中提供了这些信息。NET源代码，现在是公开的，或者使用诸如Reflector或IL Spy之类的反汇编程序，但我看不到任何东西来表示线程控制块(TCB)、程序计数器(PC)和堆栈指针(SP)或线程的等待队列，或线程当前在Thread类中所属的队列列表。
我在哪里可以读到这方面的消息？文件中有提到这些吗？我已经阅读了MSDN上的所有这些页面，但它们似乎没有提到它
。NET的线程确实是抽象的，但你基本上可以认为它们与操作系统线程几乎相同。有一些关键的区别，特别是在垃圾收集方面，但对于绝大多数程序员(阅读：不太可能启动WinDBG的程序员)来说，没有功能上的区别。
有关更多详细信息，请阅读此
在决定如何进行并发之前，对预期性能和预期并发的性质有一些想法是很重要的。例如。NET是一个虚拟机，所以模拟并发。这意味着与直接操作系统线程相比，启动执行的开销更大。
如果您的应用程序希望在需要时具有显著的并发性。NET任务或线程(甚至是ThreadPool)创建和开始执行的速度会很慢。在这种情况下，您可能会从Windows操作系统线程中受益。但是，您将希望使用非托管线程池(除非您像我一样，并且喜欢编写自己的线程池)。
如果按需启动不确定数量的线程的性能不是设计目标，那么您应该考虑。NET并发。原因是它更容易编程，并且可以利用编程语言中内置的影响并发性的关键字。
为了正确看待这一点，我编写了一个测试应用程序，测试了在不同并发执行单元中运行的算法。我在自己的非托管线程池下运行了测试。NET任务。NET线程和。NET线程池。
将并发设置为512，意味着将尽快调用512个并发执行单元，我发现了任何东西。NET的起步速度非常慢。我在几个系统上进行了测试，从16gb RAM的i5 4核台式机到Windows Server 2012 R2，结果都是一样的。
我获取了已完成的并发执行单元数、每个单元启动所需的时间以及CPU核心利用率。每次测试的持续时间为30秒。
所有的测试都产生了均衡的CPU核心利用率(与一些人的观点相反)。然而，任何事情。NET将输掉比赛。30秒后。。。
NET任务和线程(ThreadPool)有34个任务完成，平均启动时间为885ms
所有512个操作系统线程都以59ms的平均启动时间运行完成。
不管别人怎么说，从调用API开始执行单元和实际执行单元的路径要长得多。NET。