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

Question

把这个简单的功能，通过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支持的情况下，然后在没有锁定的情况下回退到一个版本的情况？我无法找到有关此行为的任何文档。

Answer 1

你的猜测看起来是正确的。从libgcc/gthr-posix.h文件中gcc的源代码库（https://github.com/gcc-mirror/gcc.git）：

/* 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; 
} 

然后在整个文件的许多并行线程的API的其余部分都包裹在里面检查到__gthread_active_p()功能。如果__gthread_active_p()返回0，则不执行任何操作并返回成功。