C++中比较和交换

Question

所以我们使用的是现在很旧的 boost 版本，在升级之前我需要为我的代码C++进行原子 CAS 操作。（我们还没有使用 C++0x）

我创建了以下 cas 函数：

inline uint32_t CAS(volatile uint32_t *mem, uint32_t with, uint32_t cmp)
{
    uint32_t prev = cmp;
    // This version by Mans Rullgard of Pathscale
    __asm__ __volatile__ ( "locknt"
            "cmpxchg %2,%0"
            : "+m"(*mem), "+a"(prev)
              : "r"(with)
                : "cc");
    return prev;
}

我使用该函数的代码如下：

void myFunc(uint32_t &masterDeserialize )
{
    std::ostringstream debugStream;
    unsigned int tid = pthread_self();
    debugStream << "myFunc, threadId: " << tid << " masterDeserialize= " << masterDeserialize << " masterAddress = " << &masterDeserialize << std::endl;
    // memory fence
    __asm__ __volatile__ ("" ::: "memory");
    uint32_t retMaster = CAS(&masterDeserialize, 1, 0);
    debugStream << "After cas, threadid = " << tid << " retMaster = " << retMaster << " MasterDeserialize = " << masterDeserialize << " masterAddress = " << &masterDeserialize << std::endl;
    if(retMaster != 0) // not master deserializer.
    {
       debugStream << "getConfigurationRowField, threadId: " << tid << " NOT master.  retMaster = " << retMaster << std::endl;
       DO SOMETHING...
    }
    else
    {
        debugStream << "getConfigurationRowField, threadId: " << tid << " MASTER. retMaster = " << retMaster << std::endl;
        DO SOME LOGIC  
        // Signal we're done deserializing.
        masterDeserialize = 0;
    }
    std::cout << debugStream.str();
}

我对这段代码的测试生成了 10 个线程，并发出所有线程的信号以使用相同的 masterDeserialize 变量调用函数。

这在大多数情况下都运行良好，但是每几千 - 几百万次测试迭代一次，2 个线程都可以进入获取 MASTER 锁的路径。

我不确定这怎么可能，或者如何避免它。

我尝试在重置masterdeserialize之前使用内存围栏，认为cpu OOO可以产生影响，但这对结果没有影响。

显然，这在具有许多内核的机器上运行，并且它是在调试模式下编译的，因此GCC不应重新排序执行以进行优化。

关于上述问题的任何建议？

编辑：我尝试使用 gcc 原语而不是汇编代码，得到了相同的结果。

inline uint32_t CAS(volatile uint32_t *mem, uint32_t with, uint32_t cmp)
{
    return __sync_val_compare_and_swap(mem, cmp, with);
}

我在多核、多 CPU 计算机上运行，但它是虚拟机，此行为是否可能是由虚拟机引起的？

Answer 1

理论上，

不仅两个线程，而且任何数量的线程都可以成为此代码中的"主人"。问题在于，在完成后采用主路径的线程将masterDeserialize变量设置回 0，从而可以通过可能很晚到达 CAS 的线程再次"获取"（例如由于抢占）。

修复实际上很简单 - 将第三个状态（例如值为 2）添加到此标志以表示"master 已完成"，并在 master 路径的末尾使用此状态（而不是初始状态 0）来表示其工作已完成。因此，只有一个调用myFunc的线程可以看到 0，这为您提供了所需的保证。若要重用该标志，需要将其显式重新初始化为 0。