为何pthread_mutex_trylock非异步信号安全？Linux与macOS、POSIX差异解析

问题背景 #

根据GitHub Issue信息，旧版LinuxThreads与新版NPTL库实现的pthread_mutex_trylock()具备异步信号安全性，但macOS并非如此。同时存在以下疑问：

• macOS下pthread_mutex_trylock()为何不具备信号安全性？
• pthread_mutex_trylock()本身为何会出现不具备信号安全性的情况？
• 如下示例代码在Linux NPTL下看似安全，但为何不符合POSIX标准？

示例代码：

static pthread_mutex_t single_exit_signal_mutex = PTHREAD_MUTEX_INITIALIZER;
static void sig_quit(int sig) //registered for SIGQUIT, SIGTERM, SIGINT
{
    // Only accept one SIGQUIT, SIGTERM, or SIGINT.
    if (pthread_mutex_trylock(&single_exit_signal_mutex) != 0)
        return;
    //...other cleanup code
}

核心解答 #

1. POSIX标准的明确边界 #

POSIX标准定义的异步信号安全函数列表中，并不包含pthread_mutex_trylock()。只有极少数线程相关函数（如pthread_self()、pthread_kill()）被纳入信号安全范畴，互斥锁的trylock/lock/unlock操作均不在此列。这意味着标准不要求操作系统实现保证这些函数在信号处理上下文内的安全性，不同平台可根据自身架构选择实现策略。

2. macOS实现的局限 #

macOS的pthread_mutex_trylock()实现存在非信号安全的设计：

• 内部可能依赖全局状态变量或非原子操作来管理锁状态，当信号处理函数打断主线程的锁操作流程时，极易导致锁数据结构损坏；
• 实现过程中可能调用了内存分配、系统调用包装等非异步信号安全的辅助函数，这些操作在信号上下文执行会触发未定义行为。

3. Linux实现的特殊性与标准冲突 #

Linux的NPTL及旧版LinuxThreads能让pthread_mutex_trylock()在信号处理中安全运行，是因为它们的互斥锁实现完全依赖原子指令完成锁尝试操作——整个过程无全局状态依赖，也不调用非信号安全函数。但这属于Linux的私有扩展实现，并不符合POSIX标准的要求：标准从未强制trylock必须具备信号安全性，因此依赖该行为的代码不具备可移植性。

4. 符合标准的替代方案 #

要实现“仅处理一次信号”的需求，应使用POSIX明确列为异步信号安全的工具：

• 用sig_atomic_t类型变量标记信号处理状态：

  static volatile sig_atomic_t signal_handled = 0;
  static void sig_quit(int sig)
  {
      if (signal_handled)
          return;
      signal_handled = 1;
      //...清理代码
  }
  

• 若必须使用互斥锁，需在信号处理函数外完成锁的获取，或通过pthread_sigmask()在关键代码段屏蔽信号，避免信号打断锁操作流程。

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