解开C++之call_once的神秘面纱：记一个有意思的问题笔记

引言

最近因为项目要求用c++，之前一直很讨厌c++，没办法只能短时间弥补c++的知识，项目中需要一个接口只调用一次，需要使用到c++的call_once机制，于是写一个小demo来测试，就因为这个足够小发现了一个非常有意思的问题。

call_once,基本原理

std::call_once 的内部实现基于两个重要的组件：std::once_flag 和 std::invoke。std::once_flag 是一个标志，用于表示某个函数是否已经被调用过。而 std::invoke 则负责实际调用该函数。

call_once的基本工作原理是：使用 std::once_flag 来标记函数是否被调用过。当有多个线程试图调用 std::call_once 时，只有一个线程会执行函数，其他线程会被阻塞直至该函数执行完毕。

std::call_once 的使用步骤三步曲：

• 创建 std::once_flag 对象：在需要保证函数只调用一次的地方创建一个 std::once_flag 对象。
• 编写需要执行一次的函数：编写你想要确保只调用一次的函数。
• 调用 std::call_once：在需要执行该函数的地方调用 std::call_once 并传入 std::once_flag 和函数名称。

demo问题引入

demo非常简单，实现一个Init函数进行call_once调用，只调用一次的函数Initialize做一次打印处理，mAIn中连续调用Init 4次，理论上来说我们执行结果只有一行打印，这也是我们的目的。

#include <IOStream>
#include <thread>
#include <mutex>
#include <atomic>

std::once_flag flag;

void Initialize()
{
        std::cout << "Run into Initialize.." << std::endl;
}

void Init()
{
        std::call_once(flag, Initialize);
}

int main(){
    Init();
    Init();
    Init();
    Init();

    return 0;
}

使用g++编译，执行结果发现出错了：

抛出了个异常，从call_once上的理解来说代码实现应该是没问题的。于是使用调试大法gdb，编译+g后使用gdb调试发现了个有意思的：

使用gdb调试发现__gthread_active_ptr指针是0，然后继续执行发现___gthread_once返回的__e为0，于是继续执行if就抛了异常。__gthread_active_ptr这又是什么呢?

深入研究研究

怎么看呢?既然不知道是什么我一般的操作是先看预处理部分代码，使用gcc -E参数来编译出call_once.i文件。

g++ -E call_once.cpp -o call_once.i

打开call_once.i文件我发现main函数部分没有什么特别之处，我们搜索call_once可以看到它的实现。

这段代码中的 std::call_once 函数首先创建了一个可调用对象 __callable，这个对象会调用传入的函数 __f，并传入 __args 参数。然后，它将 __callable 的地址存储到 __once_callable 变量中。

接下来，通过一个 lambda 表达式将 __callable 的调用封装在 __once_call 中，这个 lambda 表达式会执行 __callable。

最后，使用底层线程库的 __gthread_once 函数来确保 __once_call 只会执行一次，即保证传入的函数 __f 只会被调用一次。

如果 __gthread_once 的返回值不为零，表示执行出现了错误，会通过 __throw_system_error 抛出系统错误。

既然是if(__e)后抛的异常，我们继续看__gthread_once的实现，搜索__gthread_once关键字，找到其实现：

 11452 static inline int
 11453 __gthread_once (__gthread_once_t *__once, void (*__func) (void))
 11454 {
 11455   if (__gthread_active_p ())
 11456     return __gthrw_pthread_once (__once, __func);
 11457   else
 11458     return -1;
 11459 }

这个函数可以看到执行了__gthread_active_p ，我们继续找__gthread_active_p 的实现。

__gthread_active_p 是一个内联函数，返回一个整数值。

static void const __gthread_active_ptr 是一个静态指针常量，初始化为 __gthrw___pthread_key_create 函数的地址。

extension 是一个 GNU C 扩展，用于告知编译器避免对某些表达式进行警告。在此处，它将地址转换为 void类型，以避免类型不匹配的警告。

&__gthrw___pthread_key_create 可能是一个特定线程库(如 POSIX 线程库)内部的函数，用于创建线程特定数据的关键字。

函数返回 __gthread_active_ptr != 0，即如果该指针非空，则表明线程已激活(从指针命名上猜的)。

所以该函数用于指示线程是否被激活。不明白?我们继续看__gthrw___pthread_key_create的定义。

11405 static __typeof(pthread_key_create) __gthrw___pthread_key_create __attribute__ ((__weakref__("__pthread_key_create")));

通过 attribute((weakref("__pthread_key_create")))，将 __gthrw___pthread_key_create 弱引用到 __pthread_key_create。

弱引用是一种机制，允许在链接过程中，如果存在 __pthread_key_create 的定义，则使用它。但如果找不到 __pthread_key_create，则允许 __gthrw___pthread_key_create 仍然存在，只不过它将保持为空或未定义状态。

这里大致就明白了，总结一下，call_once内部实现中要找一个__pthread_key_create定义，如果不存在则返回空，即我们调试的时的指针给了0，从而引起异常。__pthread_key_create函数很明显是线程函数。好，那我们在代码中加上该函数调用试试看。在main开始增加如下：

int main(){
    pthread_key_t key;
    pthread_key_create(&key, NULL);
    Init();

编译运行：

达到预期效果了!

所以整体分析一下，在 call_once 的内部实现中，检测是否支持 __pthread_key_create 可能是为了确保在使用 call_once 进行线程同步时，能够利用线程特定数据键来管理状态或资源，确保其正确性和性能。如果当前环境不支持 __pthread_key_create，那么在多线程环境下可能无法有效地管理线程特定的状态信息。

因此，检测是否支持 __pthread_key_create 可能是 call_once 实现中的一种策略，用于在可能的情况下提供更好的线程安全性和性能。如果当前环境不支持这个特定的功能，可能会采用其他方式来实现 call_once，或者简化其行为以确保程序在这样的环境中仍能正确运行，尽管可能会牺牲一些特定的功能或性能。

我尝试不使用__pthread_key_create，随便调用一个pthread库的api，比如pthread_create,或者pthread_mutex_init，调用可以全部传递空指针，结果依然是可以达到预期的。所以验证也说明call_once内部通过弱引用库函数来检测当前是否支持多线程，如果不支持则抛出异常，所以使用前提必须是多线程环境。

总结

call_once 的魅力与注意事项：

std::call_once 提供了一种简单而又强大的多线程同步方式，但在使用时也需注意一些细节。比如一定要确保程序是多线程调用，如果有多线程自然还要确保线程安全，避免潜在的死锁和竞态条件问题登。