c++ - 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 版本)。因此，必须带着一点同情来阅读它所说的内容——它并没有精确地列出这方面的要求，但实现者应该“知道它的意思”并做一些让线程可用的事情。

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

Threads Cannot be Implemented as a Library涵盖了 pthreads 实际可用所需的一些特定问题，但在撰写本文时(2004 年)Posix 标准中并未明确说明。您的编译器编写者或为您的实现定义内存模型的人是否同意 Boehm 的“可用”含义，即允许程序员“令人信服地推理程序的正确性”，这一点变得非常重要。

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

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

If the compiler can inline the function and prove it does not access do_shutdown, then can it cache do_shutdown even in a multithreaded setting? What about a non-inlined function in the same compilation unit?

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

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