共享 pthread_cond_broadcast 卡在 futex

问题描述

我有一个“服务器”进程 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,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。

解决方法

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

为什么？

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

这应该如何正确完成？

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

但是请注意，有些信号无法被捕获或阻止，而上述方法对此无能为力。可以捕获其他一些信号，但强制处理程序终止程序以避免未定义的行为，而上述方法也无济于事。

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

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

共享 pthread_cond_broadcast 卡在 futex_wait

问题描述

解决方法