Linux无名POSIX信号量sem_destroy未唤醒等待线程问题咨询

你遇到的是POSIX信号量的规范定义问题，不是系统bug：

• 互斥锁pthread_mutex_destroy有明确强制要求：存在线程阻塞等待锁时，调用销毁必须返回EBUSY，不允许销毁
• 无名POSIX信号量sem_destroy没有这个约束：只要存在线程阻塞在sem_wait调用上，此时调用sem_destroy属于标准明确标注的未定义行为，内核和glibc不需要做等待者检查，也不需要唤醒等待线程，你观察到的返回0、errno为0、等待线程挂死是非常常见的实现表现——甚至部分版本下这个操作会直接触发段错误，没有任何可移植的预期行为。

要达到「销毁时阻止后续访问、唤醒所有阻塞等待线程」的效果，不能直接依赖原生sem_t的接口，需要自行封装一层信号量逻辑，下面给两种生产环境可用的实现思路：

方案1：futex轻量封装（性能最优） #

性能和原生POSIX信号量基本持平，无额外系统依赖，核心逻辑：

• 自定义信号量结构体，包含三个核心字段：原子类型的信号量计数值、销毁标记、等待线程计数
• 所有wait/post/destroy操作进入时，首先原子检查销毁标记，若已标记为销毁直接返回EINVAL，拦截所有后续访问
• 销毁流程：
  1. 原子将销毁标记置为真，保证后续新进入的等待操作直接失败
  2. 循环调用futex唤醒接口，传入INT_MAX参数唤醒所有阻塞在该信号量地址上的线程，直到等待线程计数清零
  3. 等待所有被唤醒的等待线程退出信号量访问逻辑后，再释放结构体内存
• 被唤醒的线程返回用户态后，首先检查销毁标记，如果是销毁触发的唤醒，直接返回销毁错误，不执行后续的信号量获取逻辑

核心唤醒逻辑参考代码：

// 标记销毁状态，使用release内存序保证等待线程能看到标记变更
atomic_store_explicit(&sem->destroyed, 1, memory_order_release);
// 唤醒所有阻塞等待者
while (atomic_load_explicit(&sem->waiter_cnt, memory_order_acquire) > 0) {
    syscall(SYS_futex, &sem->counter, FUTEX_WAKE, INT_MAX, NULL, NULL, 0);
}

方案2：eventfd模拟信号量（兼容性最好） #

不需要自行处理futex的等待队列逻辑，实现简单，跨内核版本兼容性极强：

• 信号量结构体包含：原子计数值、销毁标记、一个eventfd文件描述符
• 等待逻辑：先原子检查计数值，若大于0直接减计数返回；若计数值为0，则阻塞读eventfd等待通知
• post逻辑：原子增加计数值，向eventfd写入1触发一个等待线程唤醒
• 销毁流程 1. 原子标记销毁状态，拦截后续所有新请求
  2. 向eventfd写入一个远大于当前最大等待线程数的数值（比如UINT64_MAX），触发所有阻塞在eventfd读操作上的线程返回
  3. 关闭eventfd句柄，释放结构体内存
• 被唤醒的线程首先检查销毁标记，确认是销毁触发的唤醒后直接返回错误即可。这个方案额外的好处是信号量的等待可以和其他IO事件一起挂载到epoll队列上，适合事件驱动的网络编程场景。

• 不要试图通过反复调用sem_post的方式唤醒等待线程再销毁：原生信号量不提供查询当前等待线程数的接口，无法精准控制post次数，多post会导致信号量计数错乱，少post会残留线程永久阻塞
• 不要依赖当前环境下sem_destroy返回0的行为：未定义行为意味着升级内核、升级glibc后可能出现完全不同的表现，生产环境禁止在存在等待线程时直接调用原生sem_destroy

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