C Alarm信号处理中常见的竞态条件问题

Question

在使用 `alarm()` 系统调用设置定时器并结合 `SIGALRM` 信号进行超时控制时，常见的竞态条件出现在信号处理函数执行与主程序逻辑交替发生的情况下。例如，在设置 `alarm(5)` 后立即执行可能阻塞的操作，若信号在操作完成前到达，处理函数执行后 `alarm(0)` 取消防止了后续超时，但若信号恰好在检查状态与进入阻塞调用之间被触发，则可能导致超时未被正确处理或重复设置 `alarm`，引发逻辑错误。更严重的是，多个 `SIGALRM` 信号可能合并为一个，造成“信号丢失”和预期外的行为。如何保证 `alarm` 设置、清除与关键代码段的原子性，是避免此类竞态的关键技术难题。

Answer 1

1. 信号与定时器基础：alarm() 与 SIGALRM 的工作机制

在 Unix/Linux 系统中，alarm() 是一个传统的系统调用，用于设置一个单次定时器，当时间到达时会向进程发送 SIGALRM 信号。其原型如下：

#include <unistd.h>
unsigned int alarm(unsigned int seconds);

该函数返回值为距离上一次未触发的 alarm 剩余秒数，若之前无定时器则返回 0。调用 alarm(5) 后，5 秒后将产生 SIGALRM 信号。

开发者通常通过注册信号处理函数（signal handler）来响应此信号，实现超时控制。例如，在等待 I/O 操作时设置超时，防止无限期阻塞。

然而，由于信号是异步事件，其到达时机不可预测，这导致了与主程序执行流之间的交错问题，即“竞态条件”（Race Condition）。

典型场景如下：

• 调用 alarm(5)
• 进入可能阻塞的系统调用（如 read()）
• 若 SIGALRM 在 read() 返回前到达，信号处理函数执行并调用 alarm(0) 取消后续报警
• 但若信号在 alarm() 设置后、进入阻塞调用前到达，则可能导致逻辑错乱

更严重的是，传统信号模型不排队——多个 SIGALRM 会被合并为一个，造成“信号丢失”，无法准确计数或判断是否多次超时。

2. 典型竞态条件分析：从代码片段看问题本质

考虑以下伪代码结构：

sigset = 0;

void sig_alrm(int signo) {
    sigset = 1;
    alarm(0); // 取消任何待定 alarm
}

int main() {
    signal(SIGALRM, sig_alrm);
    alarm(5);
    
    while (!data_ready()) { /* 忙等检查 */ }
    
    read(fd, buf, sizeof(buf)); // 可能阻塞
    
    if (sigset) {
        printf("Timeout occurred\n");
        return -1;
    }
    // 正常处理数据
}

上述代码存在明显的竞态窗口：在 alarm(5) 和 read() 调用之间，若 SIGALRM 到达，sigset 被置位且 alarm(0) 执行，但此时并未真正需要超时处理，因为 read() 尚未开始。

反之，如果信号在 read() 阻塞期间到达，则能正确触发超时；但如果信号在检查 data_ready() 完成后、read() 开始前刚好被递送，而此时已不再需要定时器，就会误判为超时。

此外，若两次连续操作都使用 alarm()，前一次的信号处理未完成时第二次设置，可能导致定时器相互干扰。

3. 原子性保障的关键：信号屏蔽与可重入控制

要解决上述竞态，核心在于确保“设置定时器 → 执行关键区 → 清除定时器”这一序列的原子性。Linux 提供了信号集（signal set）和信号阻塞机制来实现这一点。

推荐使用 sigprocmask() 和 sigsuspend() 组合，配合 sigaction() 替代旧式 signal()。

函数	作用	是否可重入
alarm()	设置单次定时器	是
sigprocmask()	阻塞/解除阻塞指定信号	是
sigsuspend()	临时替换信号掩码并挂起	是
sigaction()	精确控制信号行为	是

4. 安全模式设计：基于 sigsuspend 的同步等待框架

以下是改进后的安全超时控制结构：

volatile sig_atomic_t g_timeout = 0;

void sig_alrm(int signo) {
    g_timeout = 1;
}

int safe_read_with_timeout(int fd, void *buf, size_t len, int timeout_sec) {
    struct sigaction sa;
    sigset_t newmask, oldmask, waitmask;

    // 设置信号处理
    sa.sa_handler = sig_alrm;
    sigemptyset(&sa.sa_mask);
    sa.sa_flags = 0;
    sigaction(SIGALRM, &sa, NULL);

    sigemptyset(&newmask);
    sigaddset(&newmask, SIGALRM);

    // 阻塞 SIGALRM
    sigprocmask(SIG_BLOCK, &newmask, &oldmask);

    alarm(timeout_sec);

    // 准备仅等待 SIGALRM 的掩码
    sigemptyset(&waitmask);
    sigdelset(&oldmask, SIGALRM); // 保留其他信号
    memcpy(&waitmask, &oldmask, sizeof(sigset_t));

    while (!g_timeout && read(fd, buf, len) == -1) {
        if (errno == EINTR) continue; // 被中断则重试
        break;
    }

    alarm(0); // 清除定时器
    g_timeout = 0;

    // 恢复原有信号掩码（不会立即处理）
    sigprocmask(SIG_SETMASK, &oldmask, NULL);

    return g_timeout ? -1 : 1;
}

该方案通过显式阻塞 SIGALRM，避免其在非预期时刻中断关键路径，并利用 sigsuspend() 实现可控唤醒（虽示例未直接使用，但可扩展）。

5. 架构级优化：从 alarm() 迁移到更现代的定时机制

虽然 alarm() 简单易用，但其全局性（每个进程只能有一个活动 alarm）限制了并发场景下的应用。对于高阶系统开发，建议转向以下替代方案：

1. timer_create() + SIGEV_THREAD：创建每线程定时器，支持高精度和多实例
2. ppoll() / pselect()：带信号掩码的 I/O 多路复用，可在等待的同时处理超时与信号隔离
3. eventfd + timerfd：结合 epoll 使用，实现用户态事件驱动定时器
4. POSIX Timers：提供 CLOCK_REALTIME 和 CLOCK_MONOTONIC 支持，避免系统时间跳变影响

以 timerfd 为例：

int tfd = timerfd_create(CLOCK_MONOTONIC, 0);
struct itimerspec its;
its.it_value = {.tv_sec = 5, .tv_nsec = 0};
timerfd_settime(tfd, 0, &its, NULL);

// 在 epoll 中监听 tfd

这种方式完全规避了信号处理的复杂性，将定时事件转化为文件描述符就绪，更适合现代服务架构。

6. 流程图：安全 alarm 使用的控制流

graph TD A[开始] --> B[注册 SIGALRM 处理函数] B --> C[阻塞 SIGALRM 信号] C --> D[调用 alarm(timeout)] D --> E[执行阻塞操作] E --> F{是否被中断?} F -- 是 --> G[检查 g_timeout 标志] G -- 超时 --> H[返回错误] G -- 非超时 --> I[重试操作] I --> E F -- 否 --> J[操作成功] J --> K[alarm(0) 清除定时器] K --> L[恢复信号掩码] L --> M[结束]

该流程确保了从设置到清除的整个过程处于信号屏蔽保护之下，有效消除竞态窗口。