c – 与位字段相邻的变量是否会被破坏？

问题的实质是GCC发出64位读访问,甚至访问1位位域.这会导致在相邻字段中读取的意外副作用,可以在程序中的其他位置进行修改.当写回修改的位域值时,也会写回相邻变量的旧值,从而丢失其他线程对其进行的任何修改.

我的问题略有不同.我有一个像这样的类/结构 –

class Group {

    uint8 adjVariable;
    volatile bool  flag1: 1;
    volatile bool  flag2: 1;
    // so on...
    volatile bool  flag10: 1;
};

访问这些变量的方式是 –

Group::fun() {
    Group_Scoped_lock();
    // adjVariable was 12 here.
    if ( adjVariable > 0 ) {
        adjVariable = 0; // <------- EXPLICIT ZERO ASSIGNMENT
    }
    // some code that doesn't affect adjVariable 
    bool1 = false;
    bool2 = false;
    bool3 = false;
    assert( adjVariable == 0 ); // <---- This assert is tripping stating that adjVariable is 12!!
}

在我们怀疑GCC的“错误”之前,我验证了是否在没有Group_lock()的情况下访问adjVariable.尽我所能,我无法在代码中看到任何发生这种情况的地方.

现在,由于编译器为位域发出64位读取并且它们是易失性的,如果它作为读取的一部分向adjVariable发出读取并且adjVariable的显式ZERO赋值仍然在缓存中,那么我们为adjVariable读取旧值12 ？这个新读取的值会覆盖显式设置值吗？因此我们绊倒了这个断言？如果是这样,我该如何验证？

在文章中,他们正在讨论丢失对其他线程中完成的相邻变量的更新,但在我的问题中,我怀疑由于从内存中读取,我们在同一线程中对adjVariable的更新失败了.这可能吗？

我们正在使用一个古老的g编译器,它在同样较旧的Fedora 12版虚拟机上只符合C 98.此外,我们只遇到一个运行了6个月的代码库,就遇到了这个问题