OpenBSD 和 Linux 上 pthread_cond_wait 的不同行为答案

【问题标题】：Different behaviour about pthread_cond_wait on OpenBSD and LinuxOpenBSD 和 Linux 上 pthread_cond_wait 的不同行为
【发布时间】：2019-03-02 20:43:57
【问题描述】：

我正在OpenBSD-current 和Arch Linux 上测试以下代码（内核版本为4.18.9）：

#include <pthread.h>

int main(void)
{
        pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
        pthread_cond_t cv = PTHREAD_COND_INITIALIZER;

        pthread_mutex_lock(&mutex);
        pthread_cond_wait(&cv, &mutex);
        return 0;
}

在OpenBSD-current: 程序不会永远退出和阻塞，这符合我的预期，因为没有线程向主线程发出信号：

# cc cv_test.c -o cv_test
# ./cv_test

但是在Arch Linux上，程序会立即退出：

# cc cv_test.c -o cv_test
# ./cv_test
#

在提到linuxmanual之后，我能出来的唯一解释是“假清醒”发生了。我运行程序几次，每次它都会立即退出。如何理解这种行为？每次都会发生“虚假清醒”吗？还是别的什么？

【问题讨论】：

你检查函数返回值是否有错误？
另外，当使用 pthreads 时，您需要使用 gcc 的 -pthread 选项进行编译。这解决了 linux 上的问题。
@Shawn 你是对的！我试过gcc和clang，他们都需要-pthread来解决这个问题。这似乎有点奇怪。您能否提供您的评论作为答案？如果您能详细说明为什么-pthread 在Linux 上如此重要，那就更好了。

标签： c linux unix pthreads

【解决方案1】：

在 Linux（可能还有其他一些操作系统）上编译多线程程序时，gcc 需要传递-pthread，这使其自动与线程库链接，并执行在该特定系统上使用线程所需的任何其他重要事情。

我不确定，但我认为 glibc 有不做任何事情的虚拟线程函数（它肯定有像 pthread_cond_wait() 这样的函数的定义，至少），这就是代码的原因没有-pthread 编译时不会出现链接器错误。

当您的代码与配置/构建系统一起使用而不是手动编译时，cmake 有FindThreads 以独立于操作系统和编译器的方式设置所需的编译器标志和库。如果使用 autoconf，autoconf macro archive 包含一个执行相同操作的 ax_pthread 宏。其他系统可能有自己的方式；这只是我熟悉的两个。

【讨论】：