销毁一个孤立的进程共享条件变量

Posted 2023-02-16

【中文标题】销毁一个孤立的进程共享条件变量

【英文标题】：destroying an orphaned process-shared condition variable

【发布时间】：2013-12-13 17:46:12

【问题描述】：

pthread_cond_destroy 在孤立的、进程共享的条件变量上的行为是指定的、未指定的、实现定义的还是未定义的？另外，我在 Linux 上看到的行为（在下面详细说明）是一个错误吗？

这里的“孤立”简历是指在服务员去世时处于pthread_cond_wait 电话中的简历。

改编自this question的场景，我发现如果我在Linux上这样做：

Time  Process A                Process B             Comments
----  ---------                ---------             --------
 1    mmap MAP_ANONYMOUS                             // or shm_open()
 2    init pshared cv
 3    init pshared mutex
 4    fork ------------------> lock(mutex)           // can also re-shm_open()
 5    wait...                  alarm(a_timeout)
 6    wait...                  cond_wait(cv, mutex)
 7    wait <------------------ <<ALRM>>
 8    cond_signal(cv)                                // (without this, EBUSY for #9)
 9    cond_destroy(cv)                               // blocks on linux

在 Linux 上，destroy() (#9) 永远阻塞。如果我忽略了孤立 cv 的信号 (#8)，那么 Linux destroy() 将返回 EBUSY。相反，在 OS X 上，destroy() 总是返回 EBUSY，无论是否发出信号。

对于它的价值，我确实不在单个多线程进程中使用进程共享互斥锁和 cvs（使用等待线程 cancel()d）在 Linux 上看到这种行为。 p>

再次，什么是规范和什么是错误？

【参考方案1】：

根据spec for pthread_cond_destroy

"销毁初始化的条件变量应该是安全的 当前没有线程被阻塞”

正是这种情况，即没有其他线程引用或阻塞在条件变量上，销毁将成功。

恕我直言，我们在两个操作系统中都有错误，因为条件变量对象处于不一致的状态。