相关疑难解决方法(0)

我知道使用绿色线程的ruby的"合作" 线程.如何在我的应用程序中创建真正的"操作系统级"线程,以便使用多个cpu内核进行处理？

如果我理解正确Node JS是非阻塞的...所以不是等待来自数据库或其他进程的响应,而是转移到其他东西并稍后检查.

它也是单线程的.

所有这些都意味着给定的Node JS进程可以完全有效地利用单个CPU核心,但它不会使用机器上的任何其他核心,因为它一次不会使用多个核心.

这当然意味着其他CPU仍然可以被其他进程用于SQL数据库或其他有意分离的CPU重子程序,只要它们是一个单独的进程即可.

此外,如果Node JS进程具有无限循环或长时间运行的函数,则在无限循环或长时间运行的函数停止(或整个进程被终止)之前,该进程不再有用.

这一切都好吗？我的理解是正确的吗？

阅读R-project网站时,有一些(不清楚)引用R的多线程,但目前还不清楚如何编译基础产品和CRAN库.

Revolution Analytics为Windows和Redhat提供多线程基础(？)下载.

其他一些Linux发行版也会包含多线程R(和包)吗？

有多种线程模型可用于在应用程序中调度线程：

• 1:1（内核级线程）：用户创建的每个线程都映射到内核中的调度线程。
• N:1（用户级线程）：用户在单个应用程序中创建的所有线程实际上都映射到单个调度的内核线程。
• M:N（混合线程）：用户在应用程序中创建的 M 个线程映射到 N 个内核线程。

用户级线程被认为比内核级线程更快，因为内核级的上下文切换比用户级的上下文切换更昂贵。用户级线程的一大缺点是它们不利用多处理器系统，因为它们只使用一个内核级线程。

有一些文章说M:N线程模型最好使用N作为CPU核心的数量（这里有一个例子）。这样我们就可以同时实现1:1和N:1线程模型的优点。

我的问题是：

1. 当我们使用内核级线程时，我们还会在执行期间获得“额外”时间片（与用户级线程相反），所以这不是弥补了缓慢的上下文切换吗？
2. 为什么 CPU 核心的数量在这里也很重要？据我了解，CPU 核心的数量在这里是相当透明的，因为即使我们使用确切数量的内核线程，也无法保证它们确实同时执行，因为其他核心可以执行其他进程中的其他线程，并且“我们的” ' 之后线程可能仍会使用上下文切换。因此，无论我们有多少个 CPU 核心，他们都会使用上下文切换。我这里错了吗？