可以 C/C++编译器通过 pthread 库调用合法地将变量缓存在寄存器中？

Question

假设我们有以下代码：

#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>

void guarantee(bool cond, const char *msg) {
    if (!cond) {
        fprintf(stderr, "%s", msg);
        exit(1);
    }
}

bool do_shutdown = false;   // Not volatile!
pthread_cond_t shutdown_cond = PTHREAD_COND_INITIALIZER;
pthread_mutex_t shutdown_cond_mutex = PTHREAD_MUTEX_INITIALIZER;

/* Called in Thread 1. Intended behavior is to block until
trigger_shutdown() is called. */
void wait_for_shutdown_signal() {

    int res;

    res = pthread_mutex_lock(&shutdown_cond_mutex);
    guarantee(res == 0, "Could not lock shutdown cond mutex");

    while (!do_shutdown) {   // while loop guards against spurious wakeups
        res = pthread_cond_wait(&shutdown_cond, &shutdown_cond_mutex);
        guarantee(res == 0, "Could not wait for shutdown cond");
    }

    res = pthread_mutex_unlock(&shutdown_cond_mutex);
    guarantee(res == 0, "Could not unlock shutdown cond mutex");
}

/* Called in Thread 2. */
void trigger_shutdown() {

    int res;

    res = pthread_mutex_lock(&shutdown_cond_mutex);
    guarantee(res == 0, "Could not lock shutdown cond mutex");

    do_shutdown = true;

    res = pthread_cond_signal(&shutdown_cond);
    guarantee(res == 0, "Could not signal shutdown cond");

    res = pthread_mutex_unlock(&shutdown_cond_mutex);
    guarantee(res == 0, "Could not unlock shutdown cond mutex");
}

符合标准的 C/C++ 编译器能否在调用 pthread_cond_wait() 时将 do_shutdown 的值缓存到寄存器中？如果不是，哪些标准/条款可以保证这一点？

编译器可以假设知道 pthread_cond_wait() 不会修改 do_shutdown。这看起来不太可能，但据我所知，没有任何标准可以阻止这种情况发生。

实际上，任何 C/C++ 编译器是否会在调用 pthread_cond_wait() 时将 do_shutdown 的值缓存在寄存器中？

哪些函数调用保证编译器不会缓存 do_shutdown 的值？很明显，如果函数是在外部声明的，并且编译器无法访问其定义，则它不能对其行为做出任何假设，因此无法证明它没有访问do_shutdown。如果编译器可以内联该函数并证明它不会访问 do_shutdown ，那么即使在多线程设置中它也可以缓存 do_shutdown 吗？同一编译单元中的非内联函数怎么样？

Answer 1

当然，当前的 C 和 C++ 标准没有提及这个主题。

据我所知，Posix 仍然避免正式定义并发模型（不过，我可能已经过时了，在这种情况下，我的答案仅适用于早期的 Posix 版本）。因此，必须带着一点同情心来阅读它所说的内容 - 它没有精确地列出该领域的要求，但实现者应该“知道它的含义”并做一些使线程可用的事情。

当标准说互斥体“同步内存访问”时，实现必须假设这意味着在一个线程的锁下所做的更改将在其他线程的锁下可见。换句话说，同步操作包括一种或另一种内存屏障是必要的（尽管还不够），并且内存屏障的必要行为是它必须假设全局变量可以更改。

线程无法作为库实现 涵盖了 pthread 实际可用所需的一些特定问题，但在撰写本文时（2004 年）Posix 标准中尚未明确说明。在允许程序员“令人信服地推理程序正确性”方面，您的编译器编写者或为您的实现定义内存模型的任何人是否同意 Boehm 的“可用”含义变得非常重要。

请注意，Posix 不保证一致的内存缓存，因此，如果您的实现反常地想要在代码的寄存器中缓存 do_something ，那么即使您将其标记为易失性，它可能会反常地选择在同步操作和读取 do_something 之间不弄脏 CPU 的本地缓存。因此，如果写入线程在具有自己的缓存的不同 CPU 上运行，即使这样您也可能看不到更改。

这就是线程不能仅作为库实现的（原因之一）。这种仅从本地 CPU 缓存获取易失性全局变量的优化在单线程 C 实现中有效[*]，但会破坏多线程代码。因此，编译器需要“了解”线程，以及它们如何影响其他语言功能（例如 pthreads 之外的示例：在 Windows 上，缓存始终是一致的，Microsoft 阐明了它授予 volatile 的附加语义 在多线程代码中）。基本上，您必须假设，如果您的实现在提供 pthreads 函数方面遇到了麻烦，那么它也会在定义一个可行的内存模型（其中锁实际上同步内存访问）方面遇到麻烦。

如果编译器可以内联
函数并证明它不访问
do_shutdown，那么是否可以缓存
do_shutdown 即使在多线程中
环境？非内联的怎么样
在同一个编译单元中运行？

对所有这些都是肯定的 - 如果该对象是非易失性的，并且编译器可以证明该线程不会修改它（通过其名称或通过别名指针），并且如果没有发生内存障碍，那么它可以重用以前的值。当然，有时可能还会存在其他特定于实现的条件来阻止它。

[*] 前提是实现知道全局不位于某个“特殊”硬件地址，这要求读取始终通过缓存到达主内存，以便查看影响该地址的任何硬件操作的结果。但是要将全局变量放在任何此类位置，或者通过 DMA 或其他方式使其位置特殊，需要特定于实现的魔法。如果没有任何这样的魔法，原则上的实现有时可以知道这一点。

Answer 2

由于 do_shutdown 具有外部链接，因此编译器无法知道调用过程中发生了什么（除非它对被调用的函数具有完全可见性）。因此，在调用后必须重新加载该值（是否易失 - 线程对此没有影响）。

据我所知，标准中没有直接说明这一点，除了标准用于定义表达式行为的（单线程）抽象机表明在表达式中访问变量时需要读取该变量。该标准允许仅在可以证明行为“好像”已重新加载的情况下优化变量的读取。只有当编译器知道该值没有被函数调用修改时，这种情况才会发生。

另外，pthread 库确实对各种函数的内存屏障做出了某些保证，包括 pthread_cond_wait() ： 用 pthread 互斥锁保护变量是否保证它也不会被缓存？

现在，如果 do_shutdown 是静态的（没有外部链接），并且您有多个线程使用同一模块中定义的静态变量（即，静态变量的地址从未被传递到另一个模块），可能是一个不同的故事。例如，假设您有一个使用此类变量的函数，并启动了为该函数运行的多个线程实例。在这种情况下，符合标准的编译器实现可能会跨函数调用缓存该值，因为它可以假设没有其他东西可以修改该值（标准的抽象机器模型不包括线程）。

因此，在这种情况下，您必须使用机制来确保在调用过程中重新加载该值。请注意，由于硬件的复杂性，volatile 关键字可能不足以确保正确的内存访问顺序 - 您应该依靠 pthread 或操作系统提供的 API 来确保这一点。 （顺便说一句，微软编译器的最新版本确实记录了易失性强制执行完整的内存屏障，但我读到的意见表明标准不要求这样做）。

Answer 3

那些挥手的答案都是错误的。抱歉说得太严厉了。

没有办法

假设编译器知道 pthread_cond_wait() 不会修改 do_shutdown。

如果您有不同的看法，请出示证据：一个完整​​的 C++ 程序，使得不是为 MT 设计的编译器可以推断出 pthread_cond_wait 不会修改 do_shutdown。

这是荒谬的，编译器不可能理解 pthread_ 函数的作用，除非它具有 POSIX 线程的内置知识。

Answer 4

从我自己的工作来看，我可以说是的，编译器可以跨 pthread_mutex_lock/pthread_mutex_unlock 缓存值。我花了一个周末的大部分时间来追踪一段代码中的一个错误，该错误是由于一组指针分配被缓存并且对于需要它们的线程不可用而引起的。作为快速测试，我将分配包装在互斥锁/解锁中，并且线程仍然无法访问正确的指针值。移动指针分配&关联的互斥锁锁定到一个单独的函数确实解决了这个问题。