multithreading - forkOn 和 -qm RTS 标志之间有什么关系？

Question

假设我有一个程序只使用 forkOn 生成线程。 .在这种情况下，不同能力之间的 Haskell 线程将没有负载平衡。那么在有没有+RTS -qm 的情况下执行这个程序有区别吗？ ?

根据文档，-qm禁用线程迁移，我认为它具有仅使用 forkOn 的类似效果.我在这个假设中正确吗？我不确定文档在这方面有多清晰。

Answer 1

我不是这方面的专家，但无论如何我都会试一试。

GHC(Haskell 编译器)可以有一个或多个HEC(Haskell Execution Context，也称为cap 或capability)。带有运行时标志 +RTS -N <number>或 setNumCapabilities 函数可以定义有多少这些 HEC 可用于程序。一个 HEC 是一个操作系统线程。运行时调度程序在 HEC 之间分配 Haskell 轻量级线程。

与 forkOn函数，可以选择在哪个 HEC 上运行线程。 getNumCapabilities 返回能力 (HEC) 的数量。

线程迁移意味着 Haskell 线程可以迁移(移动)到另一个 HEC。运行时标志 +RTS -qm禁用此线程迁移。

关于 forkOn 的文档指出

Like forkIO, but lets you specify on which capability the thread should run. Unlike a forkIO thread, a thread created by forkOn will stay on the same capability for its entire lifetime (forkIO threads can migrate between capabilities according to the scheduling policy).

所以 forkOn可以选择一个运行线程的 HEC。

与 forkIO 相比其中指出

Foreign calls made by this thread are not guaranteed to be made by any particular OS thread; if you need foreign calls to be made by a particular OS thread, then use forkOS instead.

现在，是 forkOn功能和 +RTS -qm (禁用线程迁移)同样的事情？可能不是。与 forkOn用户明确选择运行 Haskell 线程的 HEC(例如，可以将所有 Haskell 线程放入同一个 HEC)。与 +RTS -qm和 forkIO Haskell 线程不会在 HEC 之间切换，但无法知道 forkIO 生成的 Haskell 线程是哪个 HEC结束于。

引用:

Runtime Support for Multicore Haskell

The GHC scheduler

GHC(STG,Cmm,asm) illustrated