在用户空间中实现的线程库可以支持超线程吗?
Posted
技术标签:
【中文标题】在用户空间中实现的线程库可以支持超线程吗?【英文标题】:can a thread library implemented in user space support hyper-threading? 【发布时间】:2014-08-19 20:15:19 【问题描述】:假设一个多处理器架构的操作系统可能支持也可能不支持内核级线程
纠正我哪里出错了:
如果线程库完全在用户空间实现,那么线程的管理在用户空间完成(创建、线程表、堆栈信息等)。 因此,即使一个进程可能有多个用户线程,内核也只能看到 1 个单内核线程进程。 因此,内核调度将CPU使用时间分配给整个进程;用户空间线程库负责在其用户线程中对该 CPU 时间进行时间切片。 (推论 1) 具有 20 个用户线程的进程 A 将获得与具有 1 个用户线程的进程 B 相同的优先级,因此进程 A 中的线程获得大约 1/20 的 CPU 时间作为线程在进程B中 (推论 2)同一进程中的用户线程永远不会是超线程(即 2 个线程同时在不同的 CPU 上执行)【问题讨论】:
投反对票的原因? 【参考方案1】:你的前三个假设是正确的。
推论 1 取决于操作系统调度程序。调度只能基于线程,而不是进程,因此无法保证具有不同线程数的进程获得相同的总时间。
许多用户空间调度程序采用混合路线并将m
用户空间线程调度到n
OS 线程(使用m >> n
),从而避免了一些OS 线程创建的开销。如果不借助操作系统机制来引导它,就无法神奇地实现并发。
【讨论】:
调度(内核模式)如何可能与仅存在于用户空间中的概念(线程)一起工作?我认为他的第一个假设是错误的。 另外,混合模式的存在是否与第一个假设相反,即内核不知道每个进程中有多个线程? 这显然只能是协作多任务处理,其中线程定期轮询调度程序并自愿放弃。除此之外,没有什么线程不能在用户空间完成。 @AlexanderGessler 我很确定我明白你的意思。我认为这里的困惑在于我最初的假设“可能支持或不支持内核级线程的操作系统”,其中 Mooing Duck 是在后者的上下文中谈论,而 Alexander 正在谈论前者(在 m->1映射)。是吗? 是的,我想是的。我的最后一句话假设存在真正的操作系统线程。但是,用户空间协作调度在没有它们的情况下确实有效,您的假设也应该成立。以上是关于在用户空间中实现的线程库可以支持超线程吗?的主要内容,如果未能解决你的问题,请参考以下文章