我可以澄清织机计划吗？

Question

Brian让我对Loom项目感到兴奋，为了充分理解它，我需要一些关于现状的澄清。

我的理解如下:目前，为了具有真正的并行性，每个cpu/核心需要一个线程；( 1)那么在n核计算机上有n+1线程有什么意义吗？Project将通过依赖JVM在jvm内部的虚拟线程上执行任务，为我们带来几乎无限的线程/光纤。2)这是否真的是并行的?3)具体而言，这与前面提到的“n核机器上的n+1线程”有什么不同？

耽误您时间，实在对不起。

Answer 1

虚拟线程允许并发(IO绑定)，而不是并行(CPU绑定)。它们代表的是因果的同时性，而不是资源的同时使用。

实际上，如果两个虚拟线程处于IO绑定*状态(例如等待REST调用的返回)，则根本不使用线程。然而，普通线程的使用(如果不使用反应性的或可完成的语义)将被阻塞，并且在调用完成之前不可用。

*除了某些条件(例如，使用synchonize，阻塞发生在本机方法中，可能还有其他一些次要区域)。

Answer 2

那么在n核机器上有n+1线程有什么意义吗？

首先，大多数现代的n核机器都有n*2个硬件线程，因为每个核心有2个硬件线程。

有时，产生比硬件线程更多的OS线程确实是有意义的。当一些OS线程在等待某些东西时，情况就是这样。例如，在Linux上，直到几年前外行到来之前，还没有为本地磁盘上的文件实现异步I/O的好方法。传统上，磁盘密集型应用程序会产生比CPU内核更多的线程，并使用阻塞I/O。

这真的是平行的吗？

这取决于具体的实现。不仅仅是语言运行库，还包括标准库的I/O相关部分。例如，在Windows上，在C#中执行磁盘或网络I/O时，异步/等待(相当于2012年前后发布的项目)，这些任务确实是并行的，操作系统内核和驱动程序同时也在做更多的工作。Linux异步/等待上的AFAIK只对套接字真正并行，而不对文件并行，对于异步文件I/O，它使用隐藏的操作系统线程池。

具体来说，这与前面提到的“n核机器上的n+1线程”有什么不同？

OS线程的开销更高，原因有几点。(1)它们需要本机堆栈，因此每个OS线程消耗内存(2)内存慢，处理器有缓存来补偿，操作系统线程之间的切换增加了RAM带宽，因为特定于线程的数据在上下文切换(3) OS调度器经过几十年的改进后失效，但它们仍然不是免费的。一个原因是将线程状态保存/还原到/从内存中需要时间。

与切换OS线程相比，在C#异步/等待或Java中实现的高级协作多任务处理在切换上下文时造成的开销要小得多。至少在理论上，这将提高I/O重型应用程序的吞吐量和延迟。