是否有操作系统仅使用用户线程？
我们正在阅读CS课程中操作系统的基本/简单指南。该文本提供了使用1：1螺纹的多个OSS的示例，而一些以前的hybrid/ m：n。但是没有用户线程的示例/n：1。
这不是一个家庭作业问题，我真的很好奇这是什么。是否有任何OSS专门使用用户线程？还是有任何软件或编程语言可以吗？看起来正确的安排似乎很快吗？谢谢你！
永远在Google上度过，找不到任何明确的答案！
We're reading a basic/simple guide to Operating Systems in my CS class. The text gives multiple examples of OSs that use 1:1 threading, and some that formerly did hybrid/ M:N. But there are no examples of user threads/N:1.
This isn't a homework question, I'm just genuinely curious if this is or was a thing. Have any OSs utilized exclusively user threads? Or is there any software or programming language that does? It seems like with the right scheduling it could be very fast? Thank you!
Spent forever on Google and can't find any explicit answer to this!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
否（而不是您期望的方式，而是从定义上讲）。无论程序在用户空间中的感觉如何，都不是操作系统的业务，也不能被视为操作系统本身所做的事情。
从本质上讲，有3种情况：
OS是单个任务OS（并且用户空间程序使用库或其他任何在需要时提供线程的方法）。例如MS-DOS。
操作系统是多任务操作系统，OS仅知道过程（并且用户空间程序使用库或其他任何在需要时提供线程的方法）。例如早期Unix。
OS/内核提供线程（导致1：1或m：n）。
用户空间线程不是“非常快的”，对于大多数情况而言，情况明显更糟。原因是：
当有多个CPU时它无法正常工作（因此，您当前使用的不错的8核CPU将浪费87.5％）。您至少需要一个“ M：N线程”才能避免这种表现灾难。
它严重打破了线程优先级 - 例如，CPU/S浪费时间在做不重要的工作时没有完成重要的工作，因为一个过程对属于任何其他过程（或其优先级）的线程一无所知。调度程序必须注意所有线程，以避免这种性能灾难（如果一个过程知道属于所有其他过程的所有线程，则将成为安全灾难）。
几乎所有线程开关都是由设备引起的（线程必须等待磁盘，网络，键盘，“壁钟时间”，...导致调度程序必须找到其他线程来运行；而事物正在等待。由于导致线程能够再次运行，并且可能会在当时运行的重要工作不太重要）；所有设备都涉及内核（即使对于需要内核来传递消息等的微内核等）；因此，几乎所有线程开关都涉及内核。通过在用户空间中执行线程，您最终会浪费时间通知用户空间（因此用户空间可以执行某些时间表），而不是内核进行安排本身（而不会浪费时间上的通知时间）。
用户空间线程在罕见情况下不必参与其中，这是更好的，这仅限于：
线程创建和终止；但是，只有预先分配和回收内存（对于线程状态，线程堆栈，线程本地存储），并且只有完成“线程回收”（例如，预先创建的内核线程并将它们放回自由线程中）池“而不是告诉内核终止并再次创建它们）。
锁定（例如静音），其中使用锁的所有线程都属于同一过程；其中1个内核线程（并且不需要锁定）仍然比“多个用户空间线程（共享1个内核线程）争夺同一锁，并使用毫无意义的高架”。
No (and not in the way you're expecting, but by definition). Whatever a program feels like doing in user-space is none of the operating system's business and can not be considered something the OS itself does.
Essentially there's 3 cases:
the OS is a single-tasking OS (and user-space programs use libraries or whatever to provide threading if/when they want it). E.g. MS-DOS.
the OS is a multi-tasking OS, where the OS only knows about processes (and user-space programs use libraries or whatever to provide threading if/when they want it). E.g. early Unix.
the OS/kernel provides threads (leading to 1:1 or M:N).
User-space threading isn't "very fast", it's significantly worse for most things. The reasons are:
it can't work when there's multiple CPUs (so the nice 8-core CPU you're currently using becomes 87.5% wasted). You need a "M:N threading" at a minimum to avoid this performance disaster.
it breaks thread priorities badly - e.g. CPU/s wasting time doing unimportant work while important work isn't being done, because one process doesn't know anything about threads that belong to any other process (or their priorities). The scheduler must be aware of all threads to avoid this performance disaster (and if one process knows about all threads belonging to all other processes it becomes a security disaster).
almost all thread switches are caused by devices (threads having to wait for disk, network, keyboard, "wall clock time", ... causing scheduler to have to find some other thread to run; and things a thread was waiting for occurring causing the thread to be able to run again and possibly preempt less important work that was running at the time); and all devices involve the kernel (even for micro-kernels where kernel is needed to pass messages, etc); so almost all thread switches involve the kernel. By doing threading in user-space you just end up with kernel wasting time notifying user-space (so user-space can do some scheduling) instead of kernel doing the scheduling itself (without wasting time on notifications).
User-space threading is better for rare situations where kernel doesn't have to be involved anyway, which is limited to:
thread creation and termination; but only if memory (for thread state, thread stack, thread local storage) is pre-allocated and recycled, and only if "thread recycling" isn't done (e.g. pre-create kernel threads and put them back in a "free thread pool" instead of telling kernel to terminate and create them again later).
locking (e.g. mutexes) where all threads using the lock belong to the same process; where 1 kernel thread (and no need for locks) is still better than "multiple user-space threads (sharing 1 kernel thread) fighting for the same lock with extra pointless overhead".