haskell - Haskell的forkIO的实现

Question

不同的操作系统有不同的并发子系统，有操作系统进程、POSIX 线程，今天 Linux 中还有“LWP”线程，Windows 有进程、纤程、线程等。每个进程都由操作系统调度程序调度，并获得自己的 CPU 时间量。这对于 Linux “LWP”是正确的，因为它们是进程但共享内存空间，而对于用户空间线程则不然，所有线程共享一个 CPU 时间量程。

Haskell 有 forkIO。我在 Haskell 资料中发现了下一条评论:

Scheduling of Haskell threads is done internally in the Haskell runtime system, and doesn't make use of any operating system-supplied thread packages.

还

In terms of performance, 'forkOS' (aka bound) threads are much more expensive than 'forkIO' (aka unbound) threads, because a 'forkOS' thread is tied to a particular OS thread, whereas a 'forkIO' thread can be run by any OS thread. Context-switching between a 'forkOS' thread and a 'forkIO' thread is many times more expensive than between two 'forkIO' threads.

强调使用 forkIO 创建的线程不是由操作系统调度程序调度的。据我所知，它们可以免于常见的阻塞(使用 -thread 选项，当然)，但是在这种情况下，我有 3 个 Unresolved 问题:

它们(用 forkIO 创建的“线程”)如何共享这些 CPU 量子？

它们会被保证分布到不同的核心，还是因为它们由一个进程表示，不是吗？或者这是非确定性行为？

为了避免干扰效应，最好使用 forkOS 我对吗？比forkIO ?我的意思是，如果我有 2 个线程，其中一个线程提供 HTTP 服务，另一个线程进行大量磁盘 I/O 操作，那么更好的解决方案是使用 forkOS比forkIO ?

Answer 1

Haskell 线程使用协作多线程。本质上，每次 Haskell 需要分配内存时，它都会检查是否已经过去了足够的时间，如果是，则切换到下一个线程。确切的机制有点复杂(我认为在某些时候它还涉及 POSIX 信号，例如“警报”)，但这应该是主要思想。

运行时系统让 N 个 Haskell 线程在 K 个 OS 线程上运行。 K 可由用户选择。然后由操作系统决定每个操作系统线程运行的核心——这可能始终是相同的核心，也可能不是。

IO 繁重的操作应该不是什么大问题。 Haskell 运行时使用非阻塞 IO 和轮询/选择在所有线程上多路复用 IO。此外，如果您有两个正在运行的 Haskell 线程，并且您至少将两个 OS 线程专用于运行时，则这些线程应该在 OS 线程上运行，OS 应将这些线程分配给两个内核。随意尝试 forkIO对比 forkOS查看哪个为您的案例提供最佳性能，但 forkIO几乎在所有情况下都应该更好。