哪些类型的 memory_order 应该用于具有 atomic_flag 的非阻塞行为？

如何解决哪些类型的 memory_order 应该用于具有 atomic_flag 的非阻塞行为？

我希望，与其让我的线程等待，什么都不做，让其他线程完成使用数据，在此期间做其他事情（例如检查输入，或重新渲染队列中的前一帧，然后返回检查另一个线程是否完成了它的任务）。

我认为我编写的这段代码可以做到这一点，并且“似乎”可以在我执行的测试中工作，但我真的不明白 std::memory_order_acquire 和 std::memory_order_clear 是如何工作的，所以我想就我是否正确使用这些来实现我想要的行为提供一些专家建议。

另外，我以前从未见过多线程以这种方式完成，这让我有点担心。是否有充分的理由不让线程执行其他任务而不是等待？

/*test program
intended to test if atomic flags can be used to perform other tasks while shared
data is in use,instead of blocking

each thread enters the flag protected part of the loop 20 times before quitting
if the flag indicates that the if block is already in use,the thread is intended to
execute the code in the else block (only up to 5 times to avoid cluttering the output)

debug note: this doesn't work with std::cout because all the threads are using it at once
and it's not thread safe so it all gets garbled.  at least it didn't crash

real world usage
one thread renders and draws to the screen,while the other checks for input and
provides frameData for the renderer to use.  neither thread should ever block*/

#include <fstream>
#include <atomic>
#include <thread>
#include <string>

struct ThreadData {
    int numTimesToWriteToDebugIfBlockFile;
    int numTimesToWriteToDebugElseBlockFile;
};

class SharedData {
public:
    SharedData() {
        threadData = new ThreadData[10];
        for (int a = 0; a < 10; ++a) {
            threadData[a] = { 20,5 };
        }
        flag.clear();
    }

    ~SharedData() {
        delete[] threadData;
    }

    void runThread(int threadID) {
        while (this->threadData[threadID].numTimesToWriteToDebugIfBlockFile > 0) {
            if (this->flag.test_and_set(std::memory_order_acquire)) {
                std::string fileName = "debugIfBlockOutputThread#";
                fileName += std::to_string(threadID);
                fileName += ".txt";
                std::ofstream writeFile(fileName.c_str(),std::ios::app);
                writeFile << threadID << ",running,output #" << this->threadData[threadID].numTimesToWriteToDebugIfBlockFile << std::endl;
                writeFile.close();
                writeFile.clear();
                this->threadData[threadID].numTimesToWriteToDebugIfBlockFile -= 1;
                this->flag.clear(std::memory_order_release);
            }
            else {
                if (this->threadData[threadID].numTimesToWriteToDebugElseBlockFile > 0) {
                    std::string fileName = "debugElseBlockOutputThread#";
                    fileName += std::to_string(threadID);
                    fileName += ".txt";
                    std::ofstream writeFile(fileName.c_str(),std::ios::app);
                    writeFile << threadID << ",standing by,output #" << this->threadData[threadID].numTimesToWriteToDebugElseBlockFile << std::endl;
                    writeFile.close();
                    writeFile.clear();
                    this->threadData[threadID].numTimesToWriteToDebugElseBlockFile -= 1;
                }
            }
        }
    }
private:
    ThreadData* threadData;
    std::atomic_flag flag;
};

void runThread(int threadID,SharedData* sharedData) {
    sharedData->runThread(threadID);
}

int main() {
    SharedData sharedData;
    std::thread thread[10];
    for (int a = 0; a < 10; ++a) {
        thread[a] = std::thread(runThread,a,&sharedData);
    }
    thread[0].join();
    thread[1].join();
    thread[2].join();
    thread[3].join();
    thread[4].join();
    thread[5].join();
    thread[6].join();
    thread[7].join();
    thread[8].join();
    thread[9].join();
    return 0;
}```

解决方法

您在此处使用的内存顺序是正确的。

当您测试和设置您的标志（以获取您的手写锁）时的 acquire 内存顺序，非正式地说，可以防止以下代码的任何内存访问在标志出现之前变得可见测试。这就是您想要的，因为您要确保如果已经设置了标志，则不会有效地完成这些访问。同样，末尾 release 上的 clear 顺序可防止任何前面的访问在清除后变得可见，这也是您需要的，以便它们仅在持有锁时发生。

但是，使用 std::mutex 可能更简单。如果您不想等待获取锁，而是在不能时做其他事情，这就是 try_lock 的用途。

class SharedData {
    // ...
private:
    std::mutex my_lock;
}
// ...
if (my_lock.try_lock()) {
    // lock was taken,proceed with critical section
    my_lock.unlock();
} else {
    // lock not taken,do non-critical work
}

这可能会有更多的开销，但避免了考虑原子性和内存排序的需要。如果稍后变得有用，它还为您提供了轻松进行阻塞等待的选项。如果您围绕 atomic_flag 设计您的程序，然后发现必须等待获取锁的情况，您可能会发现自己在不断重试锁（这会浪费 CPU 周期）的同时陷入自旋，或诸如 std::this_thread::yield() 之类的东西，它可能会在锁定可用后等待更长的时间。

这个模式确实有点不寻常。如果总是有不需要锁的非关键工作要做，通常你会设计你的程序有一个单独的线程，它只连续执行非关键工作，然后“关键”线程可以在等待锁定时阻塞。