You need to enable JavaScript to run this app.
最新活动
大模型
产品
解决方案
定价
生态与合作
支持与服务
开发者
了解我们

纯事件驱动模型下,基于Futex的FIFO等待队列应对等待进程崩溃的无时间依赖恢复方案及替代同步原语咨询

纯事件驱动模型下,基于Futex的FIFO等待队列应对等待进程崩溃的无时间依赖恢复方案及替代同步原语咨询

核心分析

你的票证模式确实完美实现了用户态严格FIFO,但当前持票者崩溃的“活锁”问题是这类无状态票证系统的固有缺陷——因为now_serving的推进完全依赖持票者的主动操作,没有任何外部机制能验证持票者的存活状态(在无时间依赖的前提下)。

下面给出两个符合你纯事件驱动要求的解决方案:一个是基于现有Futex票证模式的无时间依赖恢复方案,另一个是直接使用Linux原生的同步原语规避该问题。


方案一:基于进程死亡事件的无时间依赖恢复(适配现有票证设计)

如果你的生产者是独立进程(而非线程),可以利用Linux的signalfd + SIGCHLD机制,以纯事件驱动的方式检测持票进程的崩溃,从而安全推进now_serving

实现步骤:

  1. 共享内存映射表:在共享内存中维护一个线程安全的哈希表(或数组,若票号范围可控),用于记录当前持有未完成票证的进程PID与对应票号my的映射关系。

    • 生产者拿到my后,立即将getpid()my存入映射表(需用原子操作或轻量互斥锁保护映射表)。
    • 生产者完成分配并推进now_serving后,从映射表中删除自己的条目。
  2. 消费者的事件驱动崩溃检测

    • 消费者调用prctl(PR_SET_CHILD_SUBREAPER, 1)(若生产者是其子进程),确保所有生产者的死亡事件都会通知到消费者。
    • 创建signalfd监听SIGCHLD信号,并将该fd加入消费者的事件循环(如epoll),实现纯事件驱动的信号处理。
    • 当消费者收到SIGCHLD事件时,循环调用waitid(P_ALL, 0, &infop, WEXITED|WNOHANG)获取所有死亡进程的PID。
    • 对每个死亡PID,查找映射表中对应的票号dead_my
      • 如果atomic_load(&now_serving) == dead_my:说明该进程是当前持票者,此时可以安全调用atomic_fetch_add(&now_serving, 1)推进状态,再调用futex_wake(&now_serving, INT_MAX)唤醒后续等待者。
      • 如果dead_my > atomic_load(&now_serving):说明该进程还未轮到自己,只需从映射表中删除条目即可,无需修改now_serving

关键优势:

  • 完全事件驱动:依赖内核的进程死亡事件通知,无超时、心跳或额外线程开销。
  • 仅需在现有票证逻辑上增加崩溃事件处理分支,无需重构核心代码。
  • 严格符合你的无时间依赖要求。

方案二:使用Linux Robust FIFO互斥锁(替代现有票证设计)

Linux的NPTL pthread_mutex提供了两个恰好匹配你需求的特性:FIFO等待队列Robust崩溃恢复,可以完全替代手动实现的票证模式,从根源上避免持票者崩溃的死锁问题。

关键特性说明:

  1. FIFO等待队列:通过设置互斥锁属性为PTHREAD_MUTEX_FUTEX_NP(现代Linux默认的PTHREAD_MUTEX_NORMAL也基于FIFO futex实现),保证等待者严格按到达顺序被唤醒,完全符合你的FIFO要求。
  2. Robustness:设置PTHREAD_MUTEX_ROBUST属性后,若持有互斥锁的线程/进程崩溃,下一个调用pthread_mutex_lock()的等待者会返回EOWNERDEAD错误(而非永久阻塞),此时你可以执行恢复逻辑并推进同步状态。

适配到你的分配器场景:

// 初始化阶段(消费者进程执行)
pthread_mutexattr_t attr;
pthread_mutexattr_init(&attr);
pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_FUTEX_NP); // 启用FIFO等待队列
pthread_mutexattr_setrobust(&attr, PTHREAD_MUTEX_ROBUST); // 启用崩溃恢复机制
pthread_mutex_t alloc_mutex;
pthread_mutex_init(&alloc_mutex, &attr);

// 生产者逻辑
int ret;
while (true) {
    ret = pthread_mutex_lock(&alloc_mutex);
    if (ret == 0) {
        // 正常获取锁,尝试分配内存
        node_t *n = palloc(size);
        if (n != NULL) {
            // 分配成功,释放锁并返回
            pthread_mutex_unlock(&alloc_mutex);
            return n;
        } else {
            // 内存不足,释放锁并等待消费者唤醒
            pthread_mutex_unlock(&alloc_mutex);
            futex_wait(&memory_available, 0); // 用futex/eventfd监听内存释放事件
        }
    } else if (ret == EOWNERDEAD) {
        // 上一个持有者崩溃,恢复锁的一致性状态
        pthread_mutex_consistent(&alloc_mutex);
        // 锁已恢复,继续尝试分配
        continue;
    } else {
        // 其他错误,处理或退出
        return NULL;
    }
}

// 消费者逻辑(释放内存后)
futex_wake(&memory_available, INT_MAX);

关键优势:

  • 内核原生支持崩溃检测与恢复,完全规避手动票证模式的死锁风险。
  • 无需维护复杂的票证状态,大幅降低代码复杂度。
  • 严格FIFO等待队列,符合你的顺序要求。
  • 纯事件驱动,无时间依赖机制。

关于“是否必须Fail-Fast”的结论

Fail-Fast是最简单的应急方案,但并非唯一正确选项。上述两个方案都能在纯事件驱动、无时间依赖的前提下安全恢复:

  • 若希望保留现有票证设计,方案一利用进程死亡事件实现恢复,适配性强。
  • 若追求更简洁可靠的实现,方案二使用Linux原生同步原语,从根源上解决问题。

如果你的生产者是线程(而非进程),方案二的robust mutex依然适用(NPTL线程崩溃会被内核检测到,robust mutex会返回EOWNERDEAD);若生产者是进程,两个方案均可行。

补充细节:Linux的futex本身无内置崩溃检测,但结合signalfd的进程死亡事件,或使用robust mutex的内核级检测,都能满足你的无时间依赖恢复要求。

火山引擎 最新活动