多线程环境中的跟随指针

Question

如果我有一些代码看起来像：

typedef struct {
    bool some_flag;

    pthread_cond_t  c;
    pthread_mutex_t m;
} foo_t;

// I assume the mutex has already been locked, and will be unlocked
// some time after this function returns. For clarity. Definitely not
// out of laziness ;)
void check_flag(foo_t* f) {
    while(f->flag)
        pthread_cond_wait(&f->c, &f->m);
}

C 标准中是否有任何内容阻止优化器将 check_flag 重写为：

void check_flag(foo_t* f) {
    bool cache = f->flag;
    while(cache)
        pthread_cond_wait(&f->c, &f->m);
}

换句话说，生成的代码是否遵循f 指针，或者编译器是否可以自由地取消引用？

如果可以随意将其拔出，有什么办法可以防止这种情况发生吗？我需要在某处撒上 volatile 关键字吗？它不可能是 check_flag 的参数，因为我计划在这个结构中包含其他变量，我不介意编译器这样优化。

我可能不得不求助于：

void check_flag(foo_t* f) {
    volatile bool* cache = &f->some_flag;
    while(*cache)
        pthread_cond_wait(&f->c, &f->m);
}

Answer 1

挥发性就是为了这个目的。不过，依靠编译器来了解 pthread 编码实践对我来说似乎有点疯狂；如今编译器非常聪明。事实上，编译器可能会看到您正在循环测试变量，并且不会因此而将其缓存在寄存器中，而不是因为它看到您使用 pthreads。如果你真的关心的话，就使用 volatile 吧。

有点有趣的小纸条。我们有一个 VOLATILE #define，它要么是“易失性”（当我们认为错误不可能是我们的代码时......）要么是空白。当我们认为由于优化器杀死我们而导致崩溃时，我们#define它“易失性”，这将易失性放在几乎所有内容的前面。然后我们进行测试，看看问题是否消失。到目前为止...错误一直是开发人员而不是编译器！谁能想到！我们开发了高性能的“非锁定”和“非阻塞”线程库。我们有一个测试平台，可以将其达到每秒数千场比赛的程度。到目前为止，我们还没有发现需要 volatile 的问题！到目前为止，gcc 从未在寄存器中缓存过共享变量。是的...我们也很惊讶。我们仍在等待使用 volatile 的机会！

Answer 2

在一般情况下，即使不涉及多线程并且您的循环如下所示：

void check_flag(foo_t* f) {
    while(f->flag)
        foo(&f->c, &f->m);
}

编译器将无法缓存 f->flag 测试。这是因为编译器无法知道函数（如上面的 foo()）是否可能更改 f 指向的任何对象。

在特殊情况下（foo() 对编译器可见，并且已知传递给 check_flag() 的所有指针都不会被 foo 别名或以其他方式修改()) 编译器也许能够优化检查。

但是，pthread_cond_wait() 的实现方式必须阻止该优化。

请参阅 是否使用以下方式保护变量pthread 互斥保证它也不会被缓存？：

您可能还对 Steve Jessop 的回答感兴趣：C/C++ 编译器可以通过 pthread 库调用合法地将变量缓存在寄存器中吗？

但是您想要多远将伯姆论文提出的问题应用到你自己的工作中取决于你。据我所知，如果您想采取 pthreads 没有/不能提供保证的立场，那么您本质上就是采取 pthreads 无用的立场（或者至少不提供安全保证，这我认为减少有相同的结果）。虽然从最严格的意义上来说这可能是正确的（如本文所述），但这也可能不是一个有用的答案。我不确定除了基于 Unix 的平台上的 pthreads 之外还有什么选择。

Answer 3

通常，您应该在等待条件对象之前尝试锁定 pthread 互斥体，因为 pthread_cond_wait 调用会释放互斥体（并在返回之前重新获取它）。因此，您的 check_flag 函数应该像这样重写，以符合 pthread 条件的语义。

void check_flag(foo_t* f) {
    pthread_mutex_lock(&f->m);
    while(f->flag)
        pthread_cond_wait(&f->c, &f->m);
    pthread_mutex_unlock(&f->m);
}

关于是否允许编译器优化flag字段的读取的问题，这个答案比我更详细地解释了它。

基本上，编译器知道pthread_cond_wait、pthread_mutex_lock和pthread_mutex_unlock的语义。他知道在这种情况下他无法优化内存读取（本例中调用pthread_cond_wait）。这里没有记忆障碍的概念，只是对某些功能的特殊知识，以及它们存在时要遵循的一些规则。

还有一件事可以保护您免受处理器执行优化的影响。如果语义保持不变，您的普通处理器能够重新排序内存访问（读/写），并且它总是这样做（因为它可以提高性能）。但是，当多个处理器可以访问同一内存地址时，就会出现这种情况。内存屏障只是向处理器发出的一条指令，告诉处理器可以移动屏障之前发出的读/写操作并在屏障之后执行它们。现在他们已经完蛋了。

Answer 4

正如所写，编译器可以按照您的描述自由地缓存结果，甚至以更微妙的方式 - 通过将其放入寄存器中。您可以通过使变量易失性来阻止这种优化的发生。但这还不够——你不应该这样编码！您应该按规定使用条件变量（锁定、等待、解锁）。

试图在图书馆周围工作是不好的，而且还会变得更糟。也许可以阅读 PLDI 2005 中 Hans Boehm 关于一般主题的论文（“线程不能作为库实现”），或他的许多后续文章（这导致了对 C++ 内存模型的修改）会让你敬畏上帝，并引导你回到正直和狭窄的地方:)。