爲什麼使用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，則不執行任何操作並返回成功。