问题标签 [nptl]

nptl/glibc 中有相当大的 commit-git：

http://sourceware.org/git/?p=glibc.git;a=commit;h=e51deae7f6ba2e490d5faeb8fbf4eeb32ae8f1ee

作者：Ulrich Drepper 和 Jakub Jelinek @ 2007

我对更改 lll_lock/lll_unlock 感兴趣

在 SMP 代码中， lll_unlock 被修改为

其中futex 地址为零并且$0是MULTIPLE_THREADS_OFFSET 常量。%P3

那么，存储在什么位置$gs:MULTIPLE_THREADS_OFFSET（又名$gs:(offsetof (tcbhead_t, multiple_threads))？这个值在程序的生命周期中是如何变化的？

NPTL 和 POSIX 线程之间的基本区别是什么？这两者是如何进化的？

我试图了解glibc 中 tls.h的以下代码段在做什么以及为什么：

fs我想我理解将寄存器中存储的值移动到__seg. 但是，我有一些问题：

1. 我的理解是fs只有16位。这个对吗？当值被移动到四字内存位置时会发生什么？这是否意味着高位被设置为 0？

2. 更重要的是，我认为__seg在段开始时声明的变量的范围仅限于该段。那么怎么__seg用呢？我确信作者glibc有充分的理由这样做，但我无法通过查看源代码来弄清楚它是什么。

我尝试为这段代码生成程序集，我得到了以下信息？

所以在我的情况下，它看起来像是eax用于__seg. 但我不知道这是否总是会发生，或者是否只是我编译的小测试文件中发生的事情。如果它总是要使用eax，为什么不这样编写程序集呢？__seg如果编译器可能会选择其他寄存器，那么由于在宏末尾超出范围，程序员如何知道要访问哪个寄存器？最后，当我在 glibc 源代码中对它进行 grep 时，我没有在任何地方看到这个宏，所以这进一步增加了我对其用途的困惑。任何关于代码在做什么以及为什么的解释都值得赞赏。

我想知道是否可以使用 nptl 而不是嵌入在我的 glibc 中的 linuxthreads 来测试特定的二进制文件。我不想重新编译 glibc，因为它是随我的特定硬件/软件提供的，我不想破坏一切。我只想能够测试这个实现，看看有什么收获

提前致谢

我很欣赏在 Linux 下，线程被映射到进程。我不清楚的是线程切换开销和使用本机 POSIX 线程库（即内核> = 2.6）的进程切换开销之间的大小差异，而且我在找到量化差异的消息灵通的文章时遇到问题。

这里有没有人有有用的参考来量化？

谢谢！

我必须实现内核级线程但是在网上搜索时我发现在linux中创建内核级线程有三种方法：

1. NPTL
2. 线程
3. linux线程

它被写在某个地方，现在已经放弃了 linuxThreads。但我找不到当前对 NPTL 和 kthread 的支持。我也找不到任何可以简单地解释我如何使用它们的功能的来源。

哪个是当前支持和使用内核级线程的好库？

还请分享任何资源来安装这些库并使用它们？

我正在尝试调试一些有关堆栈使用的代码。我制作了以下测试程序（只是作为一个例子来弄清楚 pthread 库是如何工作的）：

当我执行它时，我得到以下输出（在我的 x86_64 Ubuntu 上）：

当我进入新创建的线程时，有没有办法知道请求的 PTHREAD_STACK_MIN 还剩下多少？如果我在输入线程函数时更改 char 数组的大小，似乎限制在 7000 到 8000 之间，这不是我所期望的（在 16384 附近的某个地方）。

最近研究glibc中线程本地存储是如何实现的，发现如下代码，实现了APIpthread_key_create()

__pthread_keys是所有线程访问的全局数组。我不明白为什么其成员的读取seq不同步，如下所示：

虽然它在以后修改时是同步的。

仅供参考，__pthread_keys是一个类型为 的数组struct pthread_key_struct，其定义如下：

提前致谢。

我在 Ubuntu 12.04 LTS 服务器 x64（3.2 内核）中测试了一些代码，我认为它正在使用 NPTL。

当我跑步时

我明白了

以下是测试代码。我用 gcc -g -Wall -pthread 编译它

当我运行程序时，似乎一切都在意料之中：两个线程具有相同的 pid

但是在 htop （一个类似于 top 的工具，你可以通过 apt-get 得到它）我看到这个：两个线程有​​不同的 pid

如果我杀死 pid 2108，该进程将被杀死

如果我通过 gdb 运行程序，我可以看到LWP

我认为 NPTL 的线程共享一个 PID，而 LWP 用于内核 2.6 之前的 LinuxThreads。上面好像NPTL下还在用LWP。我对吗？我想知道 NTPL 和 LWP 的真相。

谢谢。

我正在使用 POSIX 线程审查代码，并使用 POSIX 线程的较旧 LinuxThreads 实现在 Linux 平台上运行（交叉编译代码，如果有任何区别，则以 MIPS/uClibc 为目标）。如果 NPTL 实施的答案有任何不同，为了完整起见，我也想知道这一点。这个问题pthread_t与我可以从 C 库头文件中看到的类型有关，它被定义为unsigned long intuClibc 和 glibc （实际上是嵌入式 GNU C 库——我只有 Ubuntu 可供参考）。

对于这个问题......类型的变量pthread_t用于存储属性的所有者。困扰我的是，我看到0了标记没有线程拥有该属性的分配；这让我很困扰，因为我知道 POSIX 标准规定pthread_t 类型是不透明的，我们不应该对类型做出任何假设。我知道最好使用布尔标志来确定属性是否由线程拥有。我确实认为应该修复代码以从长远来看尊重 POSIX 标准（如果不是出于其他原因，那么是为了让后代免于思考代码的稳健性），但现在短期内我需要知道回答以下问题：我们可以假设永远不能设置的pthread_t值0pthread_create(3) 在这个平台中（据我所知，我们应该得到一个值的唯一方法pthread_t），然后：赋值给 value是一种标记这个平台中0未使用的属性的可靠方法吗？