libc++中call_once为何对所有调用使用共享互斥锁？

我在阅读libc++的call_once实现时，对它使用全局共享互斥锁的设计感到疑惑。以下是相关实现代码片段：

#ifndef _LIBCPP_HAS_NO_THREADS
_LIBCPP_SAFE_STATIC static __libcpp_mutex_t mut = _LIBCPP_MUTEX_INITIALIZER;
_LIBCPP_SAFE_STATIC static __libcpp_condvar_t cv = _LIBCPP_CONDVAR_INITIALIZER;
#endif

void __call_once(volatile once_flag::_State_type& flag, void* arg,
                 void (*func)(void*)) {
  __libcpp_mutex_lock(&mut);
  ...
}

这是否意味着即使call_once(f1)和call_once(f2)调用的是不同函数，它们也会竞争同一个互斥锁？希望了解该设计是否是有意为之，以及背后的原因。

是的，所有call_once调用都会竞争同一个全局互斥锁，这个设计是有意为之的，核心原因如下：

• 简化实现+降低内存开销：如果为每个once_flag分配独立的互斥锁和条件变量，会大幅增加内存占用——尤其是当程序中存在大量once_flag时。全局共享的锁和条件变量只需要一份全局资源，把这部分开销压到最低。

• 规避once_flag自身的初始化竞态：once_flag本身（比如静态once_flag的构造）如果要关联独立锁，反而会引入新的线程安全问题。用全局锁可以在call_once入口就统一处理所有线程同步，不需要额外操心每个once_flag的锁初始化逻辑。

• 符合C++标准的最低要求：C++标准只要求同一个once_flag对应的函数仅执行一次，并没有强制要求不同once_flag的调用必须并发执行。全局锁虽然会让不同once_flag的调用串行，但完全符合标准，还简化了实现逻辑。

• 实际性能影响可接受：call_once多用于低频的初始化场景——大部分情况下，函数执行一次后，后续调用会直接返回，不会再竞争锁。只有程序启动阶段或第一次触发不同once_flag初始化时才会有竞争，这个阶段的性能损耗通常在可接受范围内。

内容的提问来源于stack exchange，提问作者Haopeng