共享 pthread_cond_broadcast 卡在 futex_wait

Question

我有一个“服务器”进程 a 并且可能有多个“客户端”进程 b。服务器创建一个共享内存文件 (shm_open)，其中包含一个 pthread_mutex_t 和一个 pthread_cond_t，用于向客户端广播发生的事情（参见下面的最小示例）。

一开始这可以正常工作，支持任意数量的客户端，但是在第一个客户端在等待广播时被杀死（例如使用 CTRL+C）后，服务器有时会卡在 pthread_cond_broadcast，或者根据 gdb 在 futex_wait 中更精确。

为什么？这应该如何正确完成？

在找到一些关于此的讨论后，我尝试过使用和不使用互斥锁以及使用和不使用互斥锁。一切都有相同的行为。

重现代码：

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/mman.h>
#include <fcntl.h>
#include <pthread.h>

struct {
    pthread_cond_t cond;
    pthread_mutex_t mutex;
} *shm;

void a() {
    // create shm and broadcast every second
    int shm_fd = shm_open("/my_shm", O_CREAT | O_RDWR, 0666);
    ftruncate(shm_fd, sizeof(*shm));
    shm = mmap(0, sizeof(*shm), PROT_READ | PROT_WRITE, MAP_SHARED, shm_fd, 0);
    close(shm_fd);

    pthread_mutexattr_t mutexattr;
    pthread_mutexattr_init(&mutexattr);
    pthread_mutexattr_setpshared(&mutexattr, PTHREAD_PROCESS_SHARED);
    pthread_mutex_init(&shm->mutex, &mutexattr);
    pthread_mutex_consistent(&shm->mutex);

    pthread_condattr_t condattr;
    pthread_condattr_init(&condattr);
    pthread_condattr_setpshared(&condattr, PTHREAD_PROCESS_SHARED);
    pthread_cond_init(&shm->cond, &condattr);

    for (int i = 0; 1; ++i) {
        pthread_mutex_lock(&shm->mutex);
        pthread_cond_broadcast(&shm->cond);
        pthread_mutex_unlock(&shm->mutex);
        sleep(1);
        printf("broadcast %d\n", i);
    }
}

void b() {
    // open shm and listen for events
    int shm_fd = shm_open("/my_shm", O_RDWR, 0666);
    shm = mmap(0, sizeof(*shm), PROT_READ | PROT_WRITE, MAP_SHARED, shm_fd, 0);
    close(shm_fd);
    for (int i = 0; 1; ++i) {
        pthread_mutex_lock(&shm->mutex);
        pthread_cond_wait(&shm->cond, &shm->mutex);
        pthread_mutex_unlock(&shm->mutex);
        printf("receive %d\n", i);
    }
}

int main(int argc, char** argv) {
    if (argc != 2)
        return -1;
    switch (argv[1][0]) {
    case 'a':
        a();
        break;
    case 'b':
        b();
        break;
    default:
        return -1;
    }
    return 0;
}

用gcc ab.c -o ab -lpthread -lrt编译，然后运行

./ab a &
./ab b
CTRL+C
./ab b

在 CTRL+C 和 ./ab b 之间的某个时间，服务器将停止输出 broadcast。

Answer 1

[...] after the first client gets killed (e.g. using CTRL+C) while waiting for the broadcast, the server sometimes gets stuck in pthread_cond_broadcast [...]

Why?

因为终止进程可能会使 CV 和/或互斥量处于不一致状态。当一个多线程进程的一个线程被强行杀死，或者当一个多线程进程分叉时，同样的事情也会发生。事实上，考虑到 b 进程大部分时间都在等待 CV，当它们被信号终止时，它们很可能会留下不一致的地方。

And how should this be done correctly?

为了防止 CV 在这种情况下变得不一致，您应该尽可能确保 b 进程在等待 CV 时不会终止。为了防止它们因接收信号而发生这种情况，请为引发标志（sig_atomic_t 类型）的信号设置一个处理程序。然后，该进程将在 return 从等待结束后检查该标志，以确定它是否需要终止。可以想见，您也可以向 CV 广播，以确保进程尽快终止。

但是请注意，有些信号无法捕获或阻止，而上述方法对这些信号无能为力。可以捕获其他一些信号，但要求处理程序终止程序以避免未定义的行为，而上述方法对这些也没有帮助。

此外，您的代码还有其他问题，包括

您不检查函数调用的 return 值，显然是假设它们总是成功。
你似乎对pthread_mutex_consistent()的语义有完全错误的想法:
1. 它仅适用于健壮的互斥量，而您的互斥量并未配置为如此。
2. 仅在 pthread_mutex_lock() 通过其 return 值表明互斥锁不一致，并且采取任何必要措施使互斥锁保护的程序状态一致后，才调用该函数是合适的。
3. 与您在评论中的声明相反，pthread_mutex_consistent() 不会解锁互斥体。它只是将互斥锁标记为已 returned 以保持一致性。在其他线程可以获取它之前，互斥量必须仍然被解锁。
4. 只有在互斥体变得不一致后第一个锁定互斥体的线程/进程才有机会使其再次一致。因此，如果您想在示例程序中使用强大的互斥量，那么 a 和 b 进程都需要准备好处理不一致的互斥量，并且在它们获取互斥量的每个点。
5. 而且由于 b 进程获取互斥锁的一个地方在 pthread_cond_wait() 内，并且它没有记录该事件的机制，因此健壮的互斥锁可能不是一个可行的选择你.

Answer 2

正如已经指出的那样，posix 定义了互斥锁的稳健性，但没有定义条件变量，将其留给编译器。正如您所发现的，GCC 条件变量并不健壮，但我相信 MUSL 是健壮的。

如果您有兴趣，我专门为强大的 IPC 编写了自己的互斥体和条件变量 https://github.com/alephzero/alephzero/blob/master/include/a0/mtx.h

共享 pthread_cond_broadcast 卡在 futex_wait

Shared pthread_cond_broadcast stuck in futex_wait

c

pthreads

shared-memory

multiprocess

futex