【问题标题】:Posix threads on smp systemsmp 系统上的 Posix 线程
【发布时间】:2017-11-15 15:58:40
【问题描述】:

我在 linux 系统中开发了一个 C 应用程序,其中有 12 个 posix 线程。它是一个多核系统。 阅读后我发现内核只知道我的进程并且它不会知道线程(posix库会照顾)。 在这种情况下,我的 12 个线程是否将仅使用一个进程被调度的内核,或者我的线程可以在所有可用内核中运行? Posix 库是否可以将线程调度到其他内核?

【问题讨论】:

  • 阅读后我发现内核只知道我的进程并且它不会知道线程(posix库会照顾)。你从哪里读到的?这可能在某些实现中是正确的,但作为一般性陈述,它介于严重过时和完全错误之间。
  • 虽然可以想象 pthreads API 可以纯粹在用户空间中实现,因此不同的线程确实不能同时在不同的内核上调度,这不是 Glibc 的方式Linux 上的实现确实有效。
  • 您可能对 Linux 没有对进程和线程进行严格区分这一事实感到困惑,但这与内核出于调度目的不知道您的线程完全不同。
  • 调度程序更喜欢在同一个核心上运行线程,因为这样它们就使用同一个缓存。这样可以提供更好的性能。
  • 确实如此,所以我不完全理解你的问题。

标签: c linux pthreads


【解决方案1】:

从历史上看,有不少库实现了类似 POSIX 线程的功能。 LinuxThreads 与 glibc 一起提供,但由于早期内核的限制(例如特定于线程的当前目录和 umask),存在严重的一致性问题。它实际上可以同时在不同 CPU 上的同一进程中运行多个线程(当时人们还没有提到内核)。 FSU 线程具有更好的 POSIX 一致性(即使在 PI 调度领域,如果我没记错的话),但仅限于每个进程一个 CPU。许多线程库还尝试了 n:m 方案,其中大量用户空间线程在少量内核调度线程(可以在不同 CPU 上并行运行)上执行。

对于 Linux 和 C/C++,当 NPTL 被添加到 glibc 并且与库的其余部分越来越紧密地集成时,这几乎停止了。 NPTL 有一个 1:1 模型:每个用户空间线程对内核都是可见的,并且可以并行运行,只要有足够的硬件资源可用。

【讨论】:

猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-03-24
相关资源
最近更新 更多