multithreading - 用户级线程和内核支持的线程之间的区别？

Question

我一直在查看基于此主题的一些注释，虽然我对线程有一般性的了解，但我不太确定用户级线程和内核级线程之间的差异 。

我知道进程基本上是由多个线程或单个线程组成，但是这些线程是前面提到的两种类型吗？

据我了解，内核支持的线程可以访问内核以进行系统调用和用户级线程无法使用的其他用途。

那么，用户级线程是否只是程序员创建的线程，然后利用内核支持的线程来执行由于其状态而无法正常执行的操作？

Answer 1

编辑:这个问题有点令人困惑，所以我用两种不同的方式回答它。

操作系统级线程与绿色线程

为了清楚起见，我通常说“操作系统级线程”或“ native 线程”，而不是“内核级线程”(我在下面的原始答案中将其与“内核线程”混淆了。)创建操作系统级线程并由操作系统管理。大多数语言都支持它们。 (C、最近的 Java 等)它们非常难用，因为你要 100% 负责防止出现问题。在某些语言中，即使是 native 数据结构(例如哈希或字典)也会在没有额外锁定代码的情况下被破坏。

操作系统线程的对立面是 green thread这是由您的语言管理的。根据语言的不同，这些线程有不同的名称(C 中的协程、Go 中的 goroutine、Ruby 中的纤程等)。这些线程仅存在于您的语言中，而不存在于您的操作系统中。因为该语言选择上下文切换(即在语句末尾)，所以它可以防止大量微妙的竞争条件(例如看到部分复制的结构，或需要锁定大多数数据结构)。程序员看到“阻塞”调用(即 data = file.read() )，但语言将其转换为对操作系统的异步调用。然后，该语言允许其他绿色线程在等待结果时运行。

绿色线程对于程序员来说要简单得多，但它们的性能各不相同:如果您有很多线程，绿色线程对于 CPU 和 RAM 来说可能更好。另一方面，大多数绿色线程语言无法利用多核。 (你甚至不能再购买单核计算机或手机了!)。一个糟糕的库可以通过阻塞操作系统调用来停止整个语言。

两全其美的方法是每个 CPU 拥有一个操作系统线程，并且许多绿色线程可以神奇地移动到操作系统线程上。像 Go 和 Erlang 这样的语言可以做到这一点。

system calls and other uses not available to user-level threads

这句话只说对了一半。是的，如果您自己调用操作系统(即做一些阻塞的事情)，您很容易引起问题。但是该语言通常有替代品，所以您甚至不会注意到。这些替换确实调用了内核，只是与您想象的略有不同。

<小时/>

内核线程与用户线程

编辑:这是我原来的答案，但它是关于用户空间线程与仅​​内核线程的问题，(事后看来)这可能不是问题。

用户线程和内核线程完全相同。 (您可以通过查看/proc/看到内核线程也在那里。)

用户线程是执行用户空间代码的线程。但它可以随时调用内核空间。尽管它以更高的安全级别执行内核代码，但它仍然被视为“用户”线程。

内核线程是一种仅运行内核代码且不与用户空间进程关联的线程。它们类似于“UNIX 守护进程”，只不过它们是仅内核守护进程。所以你可以说内核是一个多线程程序。例如，有一个内核线程用于交换。这会强制所有交换问题“序列化”到单个流中。

如果用户线程需要某些东西，它将调用内核，从而将该线程标记为 sleep 状态。随后，交换线程找到数据，因此将用户线程标记为可运行。再后来，“用户线程”从内核返回到用户态，就像什么也没发生一样。

事实上，所有线程都在内核空间中启动，因为clone()操作发生在内核空间中。 (在您可以“返回”用户空间中的新进程之前，需要执行大量内核统计操作。)