如何让线程可移植等待其他线程事件且能被信号处理程序可靠中断？

POSIX为并发线程提供了互斥锁、条件变量、信号量等同步等待机制，但这些机制都无法被运行中的信号处理程序可靠中断，具体表现如下：

• pthread_mutex_lock：标准明确规定，若信号递送给正在等待互斥锁的线程，从信号处理程序返回后，线程会继续等待互斥锁，就像从未被中断过一样。
• pthread_cond_wait：标准规定，若信号递送给正在等待条件变量的线程，从信号处理程序返回后，线程要么继续等待（仿佛未被中断），要么因虚假唤醒返回0。
• sem_wait：标准仅说明，若被信号中断，它可能以EINTR错误返回（不同于其他明确规定一定会失败的错误类型）。

此外，即便pthread_cond_wait和sem_wait的实现支持中断，也存在竞态条件：如果信号处理程序刚好在它们开始等待前运行，此时既无法阻止等待启动，也无法中断已经开始的等待——这和pthread_sigmask后紧跟select的竞态问题类似，后者需要用pselect来解决。

符合POSIX的非重量级实现方案 #

遗憾的是，不存在完全符合POSIX标准、同时又非重量级的可靠中断同步等待方案。POSIX的同步原语设计本身就没有考虑被信号可靠中断的场景，尤其是上述竞态条件无法通过标准API规避。如果要实现可靠中断，只能依赖重量级方案（比如为每个同步对象搭配文件描述符，通过pselect同时等待同步事件和信号事件）。

如果退而求其次，尝试接近“非重量级”的效果，可以用一个sig_atomic_t类型的全局中断标记（或原子变量），结合同步原语的循环等待逻辑：每次调用sem_wait或pthread_cond_wait前检查标记，等待返回后（包括处理EINTR的情况）再次检查标记。但这种方法无法解决核心竞态——信号可能刚好在检查标记之后、进入等待之前触发，导致线程还是会进入无法被中断的等待状态。

Linux特有的实现方案 #

Linux提供了几个特有的机制来解决这个问题：

1. 信号文件描述符（signalfd）
   将信号转换为文件描述符上的可读事件，这样可以用epoll、select或pselect同时监听同步事件（比如用eventfd模拟同步信号）和信号fd。当信号触发时，epoll_wait会直接返回，避免线程进入无法中断的同步等待。这种方案比传统的信号处理更可控，也能规避竞态条件。

2. pthread_mutex_timedlock + 中断标记轮询
   虽然pthread_mutex_lock无法被中断，但pthread_mutex_timedlock会在超时后返回。结合原子中断标记，线程可以循环调用pthread_mutex_timedlock，每次超时后检查标记，若标记被设置则退出循环。这种方法通过短超时轮询模拟“可中断”效果，CPU开销较小，比文件描述符方案更轻量。

3. 直接使用futex系统调用
   Linux底层的futex系统调用支持FUTEX_WAIT操作，且该操作会被信号中断并返回EINTR。你可以基于futex自行实现可被信号可靠中断的同步原语，同时通过原子变量的比较操作，把中断标记检查和futex_wait绑定在一起，从根本上避免“检查标记后、等待前触发信号”的竞态条件。

内容的提问来源于stack exchange，提问作者Joseph Sible-Reinstate Monica