编译器行为？

Question

我正在审查一些源代码，我想知道以下代码是否是线程安全的？我听说过编译器或 CPU 指令/读取重新排序(它与分支预测有关吗？)并且下面的 Data->unsafe_variable 变量可以随时被另一个线程修改。

我的问题是:根据编译器/CPU 重新排序读/写的方式，下面的代码是否可能允许 Data->unsafe_variable 被获取两次？ (见第二个片段)

注意:我不担心第一次访问，任何数据都可以存在，只要它不通过'if'，我只是担心数据可能会被在“如果”之后再次获取。我还想知道此处转换为 volatile 是否有助于防止重复提取？

int function(void* Data) {

    // Data is allocated on the heap
    // What it contains at this point is not important
    size_t _varSize = ((volatile DATA *)Data)->unsafe_variable;

    if (_varSize > x * y)
    {
        return FALSE;
    }

    // I do not want Data->unsafe_variable to be fetch once this point reached,
    // I want to use the value "supposedly" stored in _varSize
    // Would any compiler/CPU reordering would allow it to be double fetched?

    size_t size = _varSize - t * q;

    function_xy(size);

    return TRUE;
}

出于安全原因，基本上我不希望程序表现得像这样:

    _varSize = ((volatile DATA *)Data)->unsafe_variable;
    if (_varSize > x * y)
    {
        return FALSE;
    }

    size_t size = ((volatile DATA *)Data)->unsafe_variable - t * q;
    function10(size);

我在这里简化，他们不能使用互斥量。但是，在第一行之后使用 _ReadWriteBarrier() 或 MemoryBarrier() 而不是 volatile cast 会更安全吗？ (VS 编译器)

编辑:为代码提供更多上下文。

Answer 1

由于多种原因，代码已损坏。我只会指出其中一个更微妙的问题，因为其他人已经指出了更明显的问题。该对象不是 volatile。将指针强制转换为指向 volatile 对象的指针不会使对象变为 volatile，它只是依赖于编译器。

但还有更重要的一点——您的做法完全错误。你应该检查代码是否正确，也就是说，它是否保证工作。你不够聪明，没有人足够聪明，无法想出系统可能无法按照你的假设行事的每一种可能方式。因此，不要做出这些假设。

考虑 CPU 读取重新排序之类的事情完全是错误的。您应该期望 CPU 做它需要做的事情，并且只做它需要做的事情。您绝对不应该考虑它可能失败的具体机制，而应该只考虑它是否保证工作。

您所做的就像是通过检查员工是否注入(inject)了流感疫苗、是否还活着等方式来确定员工是否可以保证上类。您无法检查，甚至无法想到他可能无法出现的所有可能方式。所以如果发现你必须检查那些东西，那么它就不能保证并且依赖它是坏的。期间。

你不能通过说“CPU 不会做任何可以破坏它的事情，所以没关系”来编写可靠的代码。您可以通过说“我确保我的代码不依赖相关标准未保证的任何内容”来编写可靠的代码。

您已获得完成这项工作所需的所有工具，包括内存屏障、原子操作、互斥体等。请使用它们。

您不够聪明，无法想出所有无法保证有效的方法可能会失败。而且你有很多东西可以保证工作。修复此代码，如果可能，与编写它的人讨论如何使用正确同步。

这听起来有点粗鲁，对此我深表歉意。但是我见过太多使用像这样的“技巧”的代码，它们在测试机器上运行得很好，但当出现新的 CPU、新的编译器或新版本的操作系统时就崩溃了。像这样修复代码可能会非常痛苦，因为这些 hack 隐藏了实际的同步要求。正确的答案几乎总是清晰准确地编写您真正想要的代码，而不是假设您会得到它，因为您不知道有什么理由不会。

这是从痛苦的经历中得出的宝贵建议。