问题标签 [nptl]

If I call pthread_cond_broadcast and no one is waiting on the condition, will the pthread_cond_broadcast invoke a context switch and/or call to kernel?

If not, can I rely on it being very fast (by fast I mean, just running a small number of assmebly instruction in current process and then returning)?

惠普手册页（链接）说

“默认情况下，新线程的调度策略和优先级继承自创建线程——也就是说，默认情况下，pthread_create(3) 例程会忽略指定线程属性对象中设置的调度策略和优先级。因此，要创建受指定线程属性对象中设置的调度策略和优先级约束的线程，在调用 pthread_create(3) 之前，您的程序必须使用 pthread_attr_setinheritsched(3) 例程将继承线程
属性对象的调度属性设置为 PTHREAD_EXPLICIT_SCHED。

这适用于 Linux posix 线程（NPTL pthread）吗？

如果不是，影响使用 pthread_create() 创建的线程的优先级和调度策略的因素是什么？

我遇到了几个论坛提到的符合 POSIX 的 NPTL（本机 posix 线程库）。我想了解如何在内核（linux）的支持下实现 pthread。任何人都可以提供一个很好的材料的参考来解释 linux 中 pthreads 的设计和实现吗？

谢谢

我最近偶然发现了我认为 pthreads 库的一种非常奇怪的行为（或者至少它在 Linux Mint 16、Ubuntu EGLIBC 2.17-93ubuntu4、NPTL 2.17、gcc Ubuntu/Linaro 4.8.1-10ubuntu9 中的实现）。

在编译 pthreads 程序时，我不小心忘记将它与 pthreads 库链接（即，我忘记在 gcc 命令行中添加 -lpthread 标志）。但是，我确实编译了启用所有警告（-Wall）的程序，并且绝对没有收到任何警告或错误。当我运行程序时，我想，好像锁根本不起作用。我花了一点时间才弄明白，但最终我发现尽管所有对 pthread_mutex_lock 的调用都返回 0（成功），但并未设置锁（例如，在同一个锁上对 pthread_mutex_lock 的两次连续调用不会暂停执行）。

这是我用来测试和重现行为的概念验证代码：

如果我在没有 -lpthread 标志的情况下编译它，我不会收到任何错误或警告，当我运行它时，它会正常运行并完成执行。

如果我使用 -lpthread 标志编译它，我也不会收到任何错误或警告，但是当我运行它时，它只是挂起（在第二次调用 pthread_mutex_lock 时）——这应该是预期的行为。

任何人都可以解释为什么，当 -lpthread 标志被省略时（因此程序没有链接到 pthreads 库），编译器没有显示错误或警告，程序在执行期间也没有显示，但是 pthread_mutex_lock 只返回 0 并且没有拿着锁？

提前感谢您提供的任何线索。

这是一个元问题，因为我认为我有一个适合我的解决方案，但它有其自身的缺点和优点。我需要做一件相当普通的事情，抓住SIGSEGV一个线程（没有专门的崩溃处理线程），转储一些调试信息并退出。

这里的问题是，在崩溃时，我的应用程序运行llvm-symbolizer需要一段时间（相对而言）并导致产量（由于clone + execve或超过线程的时间量，我在自己进行符号化时看到后者发生 -过程使用libLLVM）。这样做的原因是为了得到一个带有解扰符号和行/文件信息（存储在单独的 DWP 文件中）的堆栈跟踪。出于显而易见的原因，我不希望在我的SIGSEGV处理程序中发生屈服，因为我打算在应用程序（线程组）执行后终止它并且永远不会从信号处理程序返回。

我不太熟悉 Linux 信号处理和 glibc 的包装器在它们周围做魔法，虽然，我知道基本的陷阱，但没有太多关于处理信号细节的信息，比如同步信号处理程序是否获得任何类型的特殊优先级在调度方面。

头脑风暴，我有一些想法和缺点：

• pthread_kill(<every other thread>, SIGSTOP)- 使用更多线程很麻烦，与信号处理程序交互，这似乎会产生意想不到的副作用。还需要拦截来自其他库的线程创建以跟踪线程列表，并增加每次系统调用抢占的机会。一旦它们停止指向系统调用exit存根或完全使用，甚至可能更改它们的上下文SIGKILL。
• 全局标志用作所有线程的取消点（有点像pthread_cancel/pthread_testcancel）。更安全，但需要大量维护，并且在大型代码库中它可能是地狱般的，除了轻微的性能开销。全局标志也可能导致错误级联，因为程序已经处于不可预测的状态，所以让任何其他线程在那里运行已经不是很好了。
• “滥用”我当前选择的调度程序，我的实现是答案之一。切换到FIFO调度策略并提高优先级因此成为该组中唯一可运行的线程。
• 核心转储不是一种选择，因为这里的目标是首先避免它们。除了符号器之外，我更希望不需要辅助程序。

Environment 是一个典型glibc的基于 Linux (4.4) 的发行版，带有NPTL.

我知道崩溃处理程序现在相当普遍，所以我相信我选择的方法都不是那么好，特别是考虑到我从未见过调度程序“hack”以这种方式使用过。因此，有没有人有比调度程序“hack”更清洁、风险更低的更好选择，我是否错过了关于信号的一般想法中的任何重要点？

编辑：似乎我并没有在这个等式中真正考虑过 MP（根据评论）以及其他线程在 MP 情况下仍然可以运行并且可以愉快地继续FIFO在不同处理器上与线程一起运行的事实。但是，我可以将进程的亲和性更改为仅在与崩溃线程相同的内核上执行，这基本上将有效地冻结调度边界处的所有其他线程。但是，这仍然会导致“由于阻塞 IO 导致 FIFO 线程屈服”场景处于打开状态。

似乎该FIFO + SIGSTOP选项是最好的选项，尽管我确实想知道是否有任何其他技巧可以使线程无法调度而无法使用SIGSTOP. 从文档看来，似乎不可能将线程的 CPU 亲和性设置为零（使其处于技术上可运行的边缘状态，除非没有处理器可供其运行）。

我正在阅读pthread man并看到以下内容：

使用 NPTL，一个进程中的所有线程都放在同一个线程组中；线程组的所有成员共享相同的 PID。

我当前的架构正在运行NPTL 2.17，当我运行htop显示线程时，我看到所有 PID 都是唯一的。但为什么？我期待其中一些（例如chrome）彼此共享相同的PID？

我试图通过将数组拆分为大小为 10 的段，将 1000 个元素的整数数组（其中每个元素为 1）与 pthread 库相加。因此，有效地使用了 100 个线程来执行此操作。这个并行操作的结果和预期的一样（1000）。但有趣的是，我在创建线程之前计算的顺序总和在我第一次调用pthread_join(). 不确定我是否在这里遗漏了什么。有人可以在这里发现错误吗？

在 NPTL(2.34) 库中，pthread_mutex_lock 有一个名为 __pthread_mutex_lock_full 的分支。它有什么用？