谁创建线程？程序员、操作系统、编译器还是编程语言？答案

【问题标题】：Who creates the Threads? Programmer, OS, Compiler OR Programming Language?谁创建线程？程序员、操作系统、编译器还是编程语言？
【发布时间】：2019-03-13 15:23:30
【问题描述】：

谁是线程的第一个和主要创建者？如果一种编程语言不支持线程，我们可以在其上运行多线程吗？如果操作系统不支持线程，我们可以在其上运行多线程吗？

【问题讨论】：

我认为你应该把这个问题缩小到一个特定的实现——你的问题的答案会因一个操作系统而异，所以没有具体的，唯一准确的答案是“它取决于” .
例如在 Windows 中答案是什么
所有现代版本的 Windows 都支持多线程，所以当一种编程语言的 API 想要创建一个新线程时，它会向下调用一个 Windows API 函数（例如_beginthreadex()）并且该调用处理创建一个通过 Windows 的调度程序创建新线程。
@JeremyFriesner 你的意思是CreateThread 或pthread_create
_beginthreadex()和CreateThread()都是Windows下常用的； pthread_create() 不是 Windows API 的一部分（除非微软最近添加了它并且没有告诉我；））

标签： linux windows multithreading

【解决方案1】：

Lets look at definations: Kernel-Level and User-Level threads; cs.iit.edu

用户级线程

内核级线程使并发比进程便宜得多因为，分配和初始化的状态要少得多。然而，对于细粒度的并发，内核级线程仍然受苦很多开销。线程操作仍然需要系统调用。理想情况下，我们要求线程操作与过程调用一样快。内核级线程必须是通用的，以支持所有的需求程序员、语言、运行时等。对于这样的细粒度我们仍然需要“更便宜”的线程。

为了使线程便宜又快，它们需要在用户端实现等级。用户级线程完全由运行时系统管理（用户级库）。内核对用户级线程一无所知并像管理单线程进程一样管理它们。用户级别线程小而快，每个线程由一个 PC、寄存器、堆栈和小线程控制块。创建一个新的线程、线程间切换、线程同步完成通过过程调用。即没有内核参与。用户级线程是比内核级线程快一百倍。

用户级线程的一个优点是：

这种技术最明显的优势是用户级别的线程包可以在操作系统上实现不支持线程。

所以如果编程语言支持多线程，程序员甚至可以在单线程操作系统上运行线程。

【讨论】：

【解决方案2】：

谁是线程的第一个和主要创建者？

操作系统

如果一种编程语言不支持线程，我们可以在其上运行多线程吗？

这取决于。如果该编程语言支持任何本机绑定（如 JNI/PINVOKE/Node.js 插件），您可以在该本机级别创建线程并将您的编程语言代码编组到本机线程中。

这可能是一个不完整的解决方案，因为线程还涉及内存屏障、内存排序、之前发生、共享数据等，您需要自己处理所有这些。

如果操作系统不支持线程，我们可以在其上运行多线程吗？

如果您的操作系统不支持多线程，那么没有什么可以真正填补这个空白。您可以通过让编译器在代码中插入安全点来模拟多线程，并且每次程序到达安全点时，应用程序调度程序可能会停止当前代码执行并将执行切换到另一个伪线程。简而言之，我们将这种解决方案称为“A 纤维”或“A green thread”。

有趣的是，Java 的早期版本就是这样做的，希望他们可以通过编写自己的更好的调度程序来击败 OS 调度程序，然后才明白他们并不比 Windows/Linux 内核开发团队更好。

【讨论】：

这可能是一个不完整的解决方案，因为线程还涉及内存屏障、内存排序、happens-before、共享数据等，您需要自己处理所有这些。 - 对于某些语言实现，它可能根本不起作用。考虑一下旧的 Visual Basic，它在执行每条语句时都依赖于其线程不安全的运行时库。