为啥使用 std::mutex 的函数对 pthread_key_create 的地址进行空检查？

Posted 2023-02-22

【中文标题】为啥使用 std::mutex 的函数对 pthread_key_create 的地址进行空检查？

【英文标题】：Why do functions using std::mutex make a null check of the address of pthread_key_create?为什么使用 std::mutex 的函数对 pthread_key_create 的地址进行空检查？

【发布时间】：2017-09-22 16:54:14

【问题描述】：

采用这个简单的函数，它在std::mutex 实现的锁下递增一个整数：

#include <mutex>

std::mutex m;

void inc(int& i) 
    std::unique_lock<std::mutex> lock(m);
    i++;

我希望这（内联后）以直接的方式编译为调用 m.lock() 递增 i 然后 m.unlock()。

检查生成的程序集是否有最新版本的gcc 和clang，但是，我们发现了一个额外的复杂问题。先取gcc 版本：

inc(int&):
  mov eax, OFFSET FLAT:__gthrw___pthread_key_create(unsigned int*, void (*)(void*))
  test rax, rax
  je .L2
  push rbx
  mov rbx, rdi
  mov edi, OFFSET FLAT:m
  call __gthrw_pthread_mutex_lock(pthread_mutex_t*)
  test eax, eax
  jne .L10
  add DWORD PTR [rbx], 1
  mov edi, OFFSET FLAT:m
  pop rbx
  jmp __gthrw_pthread_mutex_unlock(pthread_mutex_t*)
.L2:
  add DWORD PTR [rdi], 1
  ret
.L10:
  mov edi, eax
  call std::__throw_system_error(int)

有趣的是前几行。汇编代码检查__gthrw___pthread_key_create 的地址（这是pthread_key_create 的实现——一个创建线程本地存储键的函数），如果它是零，它分支到.L2，它实现了一个增量没有任何锁定的单条指令。

如果它不为零，则按预期进行：锁定互斥体，执行增量，然后解锁。

clang 做得更多：它检查函数的地址两次，一次在lock 之前，一次在unlock 之前：

inc(int&): # @inc(int&)
  push rbx
  mov rbx, rdi
  mov eax, __pthread_key_create
  test rax, rax
  je .LBB0_4
  mov edi, m
  call pthread_mutex_lock
  test eax, eax
  jne .LBB0_6
  inc dword ptr [rbx]
  mov eax, __pthread_key_create
  test rax, rax
  je .LBB0_5
  mov edi, m
  pop rbx
  jmp pthread_mutex_unlock # TAILCALL
.LBB0_4:
  inc dword ptr [rbx]
.LBB0_5:
  pop rbx
  ret
.LBB0_6:
  mov edi, eax
  call std::__throw_system_error(int)

这项检查的目的是什么？

也许是为了支持目标文件最终编译成没有 pthreads 支持的二进制文件的情况，然后在这种情况下回退到没有锁定的版本？我找不到有关此行为的任何文档。

【参考方案1】：

您的猜测似乎是正确的。来自 gcc 源代码库 (https://github.com/gcc-mirror/gcc.git) 中的 libgcc/gthr-posix.h 文件：

/* For a program to be multi-threaded the only thing that it certainly must
   be using is pthread_create.  However, there may be other libraries that
   intercept pthread_create with their own definitions to wrap pthreads
   functionality for some purpose.  In those cases, pthread_create being
   defined might not necessarily mean that libpthread is actually linked
   in.

   For the GNU C library, we can use a known internal name.  This is always
   available in the ABI, but no other library would define it.  That is
   ideal, since any public pthread function might be intercepted just as
   pthread_create might be.  __pthread_key_create is an "internal"
   implementation symbol, but it is part of the public exported ABI.  Also,
   it's among the symbols that the static libpthread.a always links in
   whenever pthread_create is used, so there is no danger of a false
   negative result in any statically-linked, multi-threaded program.

   For others, we choose pthread_cancel as a function that seems unlikely
   to be redefined by an interceptor library.  The bionic (android) C
   library does not provide pthread_cancel, so we do use pthread_create
   there (and interceptor libraries lose).  */

#ifdef __GLIBC__
__gthrw2(__gthrw_(__pthread_key_create),
     __pthread_key_create,
     pthread_key_create)
# define GTHR_ACTIVE_PROXY  __gthrw_(__pthread_key_create)
#elif defined (__BIONIC__)
# define GTHR_ACTIVE_PROXY  __gthrw_(pthread_create)
#else
# define GTHR_ACTIVE_PROXY  __gthrw_(pthread_cancel)
#endif

static inline int
__gthread_active_p (void)

  static void *const __gthread_active_ptr
    = __extension__ (void *) &GTHR_ACTIVE_PROXY;
  return __gthread_active_ptr != 0;

然后在文件的其余部分中，许多 pthread API 都包含在对 __gthread_active_p() 函数的检查中。如果__gthread_active_p() 返回 0，则什么都不做，返回成功。

【讨论】：

很好的答案，谢谢。您还回答了我的（未说明的）第二个问题，即此行为是否由编译器实现，该编译器“知道”使用 pthreads 的方法并编译专门使用它们的方法，或者检查是否实际上只是在 glibc/pthreads 源中（是后者）。这也解释了为什么 clang 有两个检查：两个检查是 默认的 但 gcc 只是设法将这些检查合并为一个，基本上编译了两个不同版本的方法，而 clang 没有至少可以在-O2 合并检查。

我对 GCC 内部结构不是很熟悉，但看起来这不是在 glibc/pthreads 中实现的，而是在 gcclib 中实现的，这是编译器使用的“低级运行时库” .看起来 libgcc 可能依赖于正在使用的 libc，这是我没想到的。但可能我只是不完全了解发生了什么。

好点，根据我的快速浏览，它似乎在libgcc 支持库中，而不是在glibc 中，这确实意味着它可能更紧密地绑定到编译器。跨度>