linux - pthread_self 返回一个大整数或 0，这取决于 libpthread 是否存在

Question

#include <pthread.h>
#include <iostream>
 int main(){
     std::cout<<pthread_self()<<std::endl;
}

当使用命令g++ 1.cpp -o 1编译并执行时，程序输出为0，如果使用命令g++ 1.cpp编译-o 1 -lpthread 输出是一个很大的数字，如 140062699310912。

我不明白为什么。

# g++ 1.cpp -o 1 && ./1
0
# g++ 1.cpp -o 1 -lpthread && ./1
140268785461056

Answer 1

POSIX 标准没有指定 pthread_t 的实际类型对应。在 glibc 中，它是 unsigned long int ，这就是 C++ 流可以打印其值的原因。 (这不是可移植的。)

为什么 pthread_self返回零，但仅当不与-lpthread 链接时？

从历史上看，glibc 支持两种不同的线程库实现，LinuxThreads 和 NPTL。一些核心libpthread函数在 glibc 本身中有 stub ，如果加载了任何 stub ，它们会转发到实际实现，或者如果进程中不存在线程库，则执行一些虚拟回退操作。例如，pthread_mutex_lock 的虚拟实现和 pthread_mutex_unlock什么都不做。

在pthread_self的情况下，虚拟实现必须返回一些值，并且这个值为零。 (POSIX 不保留任何 pthread_t 值来指示失败或其他极端情况，所以这很好。)当与 -lpthread 链接时，使用非虚拟实现，它返回一个指向内部线程数据结构的指针(转换为 unsigned long )，并且这个值永远不会为零，即使对于初始(主)线程也是如此。这就是为什么 -lpthread 存在的原因在链接器命令行上很重要。

其他人无法重现此行为，因为他们要么使用非 glibc 系统，要么使用更新版本的 glibc。现在，glibc 只有一个线程库实现，最初是 NPTL，它与 glibc 的其余部分紧密集成。这意味着不再需要转发器，在 glibc 2.27 中， pthread_self never returns zero .顺便说一句，此更改有助于实现 std::thread ，其中 get_id() 返回的值为零: std::thread::id{}意味着没有 ID，而不是该线程是主线程(如在未加载 libpthread 的旧 glibc 版本中)。 libstdc++因此需要一个 kludge 来支持 glibc 2.26 及更早版本。

转发器还有另一个好处:它们可以实现性能优化，而不仅仅是为了 pthread_mutex_lock (如果未链接 libpthread，则不执行任何操作)。一些libpthread没有 -lpthread 的功能可用.这意味着应用程序可以使用同步并且它们可以检查是否存在符号，例如pthread_create。或 pthread_cancel (使用弱符号引用)。如果这些weak symbols是undefined，很明显这个进程一定是单线程的，如libpthread不存在，这意味着不能创建线程。在这种情况下，例如，没有必要使用原子指令来进行引用计数。 (std::shared_ptr in libstdc++ 使用了这样的优化。)但是这种优化越来越无效，因为大多数过程镜像包含 libpthread这些天:一些库需要它，所以它作为间接依赖加载。这意味着转发器也失去了这个其他目的，并且它们正逐渐从 glibc 中删除。 (glibc 2.32 添加了 __libc_single_threaded 以启用单线程优化，即使加载了 libpthread，但还没有创建线程。)