共享 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

[...] 在第一个客户端被杀死后（例如，使用 CTRL+C）等待 对于广播，服务器有时会卡在 pthread_cond_broadcast [...]

为什么？

因为杀死进程可能会使 CV 和/或互斥体处于不一致的状态。当多线程进程的一个线程被强行杀死或多线程进程分叉时，可能会发生相同的一般情况。实际上，鉴于b 进程大部分时间都在等待 CV，当它们被信号终止时，它们很可能会留下不一致的情况。

这应该如何正确完成？

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

但请注意，某些信号无法被捕获或阻止，并且上述方法无法对这些信号做任何事情。可以捕获其他一些信号，但强制处理程序终止程序以避免未定义的行为，而上述方法也无济于事。

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

• 您不检查函数调用的返回值，显然假设它们总是成功。

• 你似乎对pthread_mutex_consistent()的语义有完全错误的想法：

  1. 它仅适用于健壮的互斥锁，而您的互斥锁未配置。
  2. 只有在pthread_mutex_lock() 通过其返回值表明互斥体不一致，并且在采取任何必要措施使互斥体保护的程序状态一致之后，才适合调用该函数。
  3. 与您在 cmets 中的声明相反，pthread_mutex_consistent() 不解锁互斥锁。它只是将互斥体标记为已恢复一致性。互斥锁仍必须解锁，其他线程才能获取它。
  4. 只有第一个在互斥体变得不一致后锁定互斥体的线程/进程才有机会再次使其一致。因此，如果您想在示例程序中使用强大的互斥锁，那么 a 和 b 进程都需要准备好处理不一致的互斥锁，并且在它们获取互斥锁的每个点上都需要做好准备。
  5. 而且由于b 进程获取互斥锁的一个地方位于pthread_cond_wait() 内部，并且它没有记录的机制来报告该事件，因此强大的互斥锁可能不是您的可行选择。