C++11：具有互斥锁的线程看到原子变量的值发生变化，尽管这是唯一可以改变它的代码

一个原子变量(在本例中为128位结构)正在更新，这让唯一有能力更新它的线程感到惊讶。这是怎么回事

这是一个最小的例子，所以它不会做任何有意义的事情，但是：alloc()函数返回一个malloc'd缓冲区100次，然后分配一个新的缓冲区，它将返回100次，以此类推，即使面对被多个线程调用的情况。

我有一个原子变量，它是一个带有指针、32位int和另一个32位计数器的结构，旨在避免ABA问题。

我有一个分为两部分的函数。第一部分将，如果返回计数为非零，则CAS结构将递减返回计数(并递增ABA计数器)，然后返回指针。否则，第二部分获得一个互斥对象，为一个新指针分配内存，CAS的小结构完全带有新指针、一个新的非零返回计数器，以及ABA计数器的一个增量。

简而言之，当计数器大于零时，每个线程都可以更新这个结构。但一旦它为零，第一个获取互斥对象的线程，我认为，将是唯一可以再次CAS更新此结构的线程。

但有时CAS会失败！"它怎么会失败"是我的问题

下面是一个运行示例。它可以用g++ lockchange.cxx -o lockchange -latomic -pthread编译。它在Fedora 31上的gcc version 9.2.1 20190827 (Red Hat 9.2.1-1) (GCC)上运行。

#include <algorithm>
#include <atomic>
#include <chrono>
#include <cassert>
#include <cstring>
#include <mutex>
#include <thread>
#include <vector>
using namespace std;

struct MyPair { /* Hungarian: pair */
char*    pc;         /* a buffer to be used n times */
int32_t  iRemaining; /* number of times left to use pc */
uint32_t iUpdates;   /* to avoid ABA problem */
};

const int iThreads{ 200 };
const int iThreadIterations{ 1000000 };
const int iSizeItem{ 128 };
mutex mux;
atomic<MyPair> pairNext;

char* alloc() {
TRY_AGAIN:
MyPair pairCur = pairNext.load();
// CASE 1: We can use the existing buffer?
while ( pairCur.iRemaining ) {
char* pcRV = pairCur.pc;
MyPair pairNew = { pairCur.pc,
pairCur.iRemaining - 1,
pairCur.iUpdates + 1 };
if ( pairNext.compare_exchange_weak( pairCur, pairNew ) )
return pcRV;
// Otherwise, pairNext was changed out from under us and pairCur
// will have been updated.  Try again, as long as iRemaining
// non-zero.
}

// CASE 2: We've used pc as many times as allowed, so allocate a new pc.
// Get a mutex as we'll be changing too many fields to do atomically.
lock_guard<mutex> guard( mux );
// If multiple threads saw iRemaining = 0, they all will
// have tried for the mutex; only one will have gotten it, so
// there's a good chance that by the time we get the mutex, a
// sibling thread will have allocated a new pc and placed it at
// pairNext, so we don't need to allocate after all.
if ( pairNext.load().iRemaining ) // <=============================== it's as if this line isn't seeing the update made by the line below in real time.
goto TRY_AGAIN;
// Get a new buffer.
char* pcNew = (char*) malloc( iSizeItem );
MyPair pairNew = { pcNew, 100, pairCur.iUpdates + 1 };
if ( pairNext.compare_exchange_strong( pairCur, pairNew ) ) { //<===== the update that's not being seen above in real time
// *** other stuff with pcNew that needs mutex protection ***;
return pcNew;
} else {
// CASE 2c: after allocating a new page, we find that
// another thread has beaten us to it.  I CAN'T FIGURE OUT
// HOW THAT'S POSSIBLE THOUGH.  Our response should be safe
// enough: put our allocation back, and start all over again
// because who knows what else we missed.  I see this error
// like 813 times out of 40 BILLION allocations in the
// hammer test, ranging from 1 to 200 threads.
printf( "unexpected: had lock but pairNext changed when iRemaining=0n" );
// In fact the following free and goto should and seem to
// recover fine, but to be clear my question is how we can
// possibly end up here in the first place.
abort();
free( pcNew );
goto TRY_AGAIN;
}
}

void Test( int iThreadNumber ) {
for ( int i = 0; i < iThreadIterations; i++ )
alloc();
}

int main( int nArg, char* apszArg[] ) {
vector<thread> athr;
for ( int i = 0; i < iThreads; i++ )
athr.emplace_back( Test, i );
for ( auto& thr: athr )
thr.join();
}