std:: memory_order

std::memory_order 는 원자적 연산을 중심으로 일반적인 비원자적 메모리 접근을 포함한 메모리 접근들이 어떻게 순서화되어야 하는지를 지정합니다. 다중 코어 시스템에서 아무런 제약이 없는 경우, 여러 스레드가 동시에 여러 변수를 읽고 쓸 때, 한 스레드는 다른 스레드가 값을 기록한 순서와 다른 순서로 값이 변경되는 것을 관찰할 수 있습니다. 실제로 변경 사항의 명백한 순서는 여러 독자 스레드 간에도 서로 다를 수 있습니다. 메모리 모델이 허용하는 컴파일러 변환으로 인해 유니프로세서 시스템에서도 유사한 효과가 발생할 수 있습니다.

라이브러리의 모든 원자적 연산의 기본 동작은 순차적 일관성 순서 를 제공합니다(아래 논의 참조). 이 기본값은 성능에 영향을 미칠 수 있지만, 라이브러리의 원자적 연산에 추가적인 std::memory_order 인수를 지정하여 원자성 이상의 정확한 제약 조건을 컴파일러와 프로세서가 해당 연산에 대해 강제하도록 할 수 있습니다.

상수

공식 설명

스레드 간 동기화와 메모리 순서는 서로 다른 실행 스레드들 사이에서 표현식의 평가(evaluations) 와 부수 효과(side effects) 가 어떻게 순서화되는지를 결정합니다. 이들은 다음 용어들로 정의됩니다:

Sequenced-before

동일한 스레드 내에서, 평가 A는 평가 순서 에 설명된 대로 평가 B보다 sequenced-before 될 수 있습니다.

수정 순서

특정 원자 변수에 대한 모든 수정은 해당 원자 변수에 특화된 전체 순서로 발생합니다.

모든 원자적 연산에 대해 다음 네 가지 요구 사항이 보장됩니다:

릴리스 시퀀스

원자적 객체 M에 대해 release 연산 A가 수행된 후, M의 수정 순서 중 다음으로 구성된 가장 긴 연속 부분 순서:

A에 의해 시작된 릴리스 시퀀스 로 알려져 있습니다.

동기화 대상

스레드 A의 원자적 저장 연산이 release operation 이고, 동일한 변수에 대한 스레드 B의 원자적 로드 연산이 acquire operation 이며, 스레드 B의 로드 연산이 스레드 A의 저장 연산이 기록한 값을 읽는 경우, 스레드 A의 저장 연산은 스레드 B의 로드 연산과 synchronizes-with 관계를 형성합니다.

또한, 일부 라이브러리 호출은 다른 스레드의 다른 라이브러리 호출과 synchronize-with 되도록 정의될 수 있습니다.

스레드 간 happens-before

스레드 간에, 평가 A가 inter-thread happens before 평가 B인 경우는 다음 중 하나가 참일 때입니다:

강력하게 선행(Strongly happens-before)

스레드와 관계없이, 다음 중 하나라도 참이면 평가 A가 평가 B에 대해 강하게 선행 발생(strongly happens-before) 합니다:

가시적 부작용

스칼라 M에 대한 부작용 A(쓰기)는 다음 두 조건이 모두 참일 때 M에 대한 값 계산 B(읽기)에 대해 가시적 입니다:

부작용 A가 값 계산 B와 관련하여 가시적이라면, M에 대한 부작용들 중 가장 긴 연속된 부분집합으로서, 수정 순서 상에서 B가 그것에 선행하지 않는 부분을 가시적 부작용 시퀀스 라고 합니다 (B에 의해 결정되는 M의 값은 이러한 부작용 중 하나에 의해 저장된 값이 됩니다).

참고: 스레드 간 동기화는 데이터 경쟁(선행 관계를 설정하여)을 방지하고 어떤 조건에서 어떤 부작용이 표시되는지 정의하는 것으로 귀결됩니다.

소비 연산

memory_order_consume 또는 그 이상의 메모리 순서를 사용하는 원자적 로드는 소비 연산(consume operation)입니다. std::atomic_thread_fence 는 소비 연산보다 더 강력한 동기화 요구 사항을 부과한다는 점에 유의하십시오.

Acquire 연산

memory_order_acquire 또는 그 이상의 메모리 순서를 사용한 원자적 로드는 획득 연산입니다. Mutex 의 lock() 연산 또한 획득 연산입니다. std::atomic_thread_fence 는 획득 연산보다 더 강력한 동기화 요구사항을 부과한다는 점에 유의하십시오.

릴리스 연산

memory_order_release 또는 그보다 강한 메모리 순서를 사용한 원자적 저장(atomic store)은 릴리스 연산입니다. Mutex 의 unlock() 연산 또한 릴리스 연산입니다. std::atomic_thread_fence 는 릴리스 연산보다 더 강력한 동기화 요구사항을 부과한다는 점에 유의하십시오.

설명

릴렉스드 오더링

memory_order_relaxed 태그가 지정된 원자 연산은 동기화 연산이 아닙니다; 이들은 동시적 메모리 접근 간에 순서를 부과하지 않습니다. 오직 원자성과 수정 순서 일관성만을 보장합니다.

예를 들어, x 와 y 가 초기에 0인 경우,

// 스레드 1:
r1 = y.load(std::memory_order_relaxed); // A
x.store(r1, std::memory_order_relaxed); // B
// 스레드 2:
r2 = x.load(std::memory_order_relaxed); // C 
y.store(42, std::memory_order_relaxed); // D

r1 == r2 == 42 가 허용되는 이유는, 스레드 1 내에서 A가 B보다 sequenced-before 관계에 있고 스레드 2 내에서 C가 D보다 sequenced before 관계에 있지만, y 의 수정 순서에서 D가 A보다 먼저 나타나는 것을 막는 것은 없으며, x 의 수정 순서에서 B가 C보다 먼저 나타나는 것을 막는 것도 없기 때문입니다. y 에 대한 D의 부작용이 스레드 1의 로드 A에 보일 수 있고, x 에 대한 B의 부작용이 스레드 2의 로드 C에 보일 수 있습니다. 특히, 컴파일러 재배치나 런타임 중에 스레드 2에서 C보다 D가 먼저 완료되는 경우 이런 현상이 발생할 수 있습니다.

// Thread 1:
r1 = y.load(std::memory_order_relaxed);
if (r1 == 42)
    x.store(r1, std::memory_order_relaxed);
// Thread 2:
r2 = x.load(std::memory_order_relaxed);
if (r2 == 42)
    y.store(42, std::memory_order_relaxed);

완화된 메모리 순서의 일반적인 사용 예는 참조 카운터와 같은 카운터 증분입니다. std::shared_ptr 의 참조 카운터가 이에 해당합니다. 이는 원자성만 필요로 하고 순서나 동기화는 필요하지 않기 때문입니다(단, std::shared_ptr 카운터 감소는 소멸자와의 획득-해제 동기화가 필요함에 유의하세요).

#include <atomic>
#include <iostream>
#include <thread>
#include <vector>
std::atomic<int> cnt = {0};
void f()
{
    for (int n = 0; n < 1000; ++n)
        cnt.fetch_add(1, std::memory_order_relaxed);
}
int main()
{
    std::vector<std::thread> v;
    for (int n = 0; n < 10; ++n)
        v.emplace_back(f);
    for (auto& t : v)
        t.join();
    std::cout << "Final counter value is " << cnt << '\n';
}

Final counter value is 10000

릴리스-어퀴어 순서 지정

스레드 A의 원자적 저장 연산이 memory_order_release 로 태그되고, 동일한 변수에 대한 스레드 B의 원자적 로드 연산이 memory_order_acquire 로 태그되며, 스레드 B의 로드 연산이 스레드 A의 저장 연산이 기록한 값을 읽는 경우, 스레드 A의 저장 연산은 스레드 B의 로드 연산과 동기화됩니다(synchronizes-with) .

스레드 A의 관점에서 원자적 저장 이전에 happened-before 관계에 있는 모든 메모리 기록(비원자적 및 완화된 원자적 기록 포함)은 스레드 B에서 visible side-effects 가 됩니다. 즉, 원자적 로드가 완료되면 스레드 B는 스레드 A가 메모리에 기록한 모든 내용을 보게 됩니다. 이 약속은 B가 실제로 A가 저장한 값이나 릴리스 시퀀스에서 이후의 값을 반환하는 경우에만 유효합니다.

동기화는 동일한 원자 변수를 해제하는 스레드와 획득하는 스레드 사이에서만 확립됩니다. 다른 스레드들은 동기화된 스레드 중 하나 또는 둘 모두와 다른 메모리 접근 순서를 관찰할 수 있습니다.

강력하게 정렬된 시스템(x86, SPARC TSO, IBM 메인프레임 등)에서는 대부분의 연산에 대해 릴리스-획득 순서가 자동으로 적용됩니다. 이 동기화 모드에는 추가적인 CPU 명령어가 발생하지 않으며, 특정 컴파일러 최적화만 영향을 받습니다(예: 컴파일러는 비원자적 저장을 원자적 저장-릴리스 이후로 이동하거나 비원자적 로드를 원자적 로드-획득보다 앞서 수행하는 것이 금지됩니다). 약하게 정렬된 시스템(ARM, Itanium, PowerPC)에서는 특수 CPU 로드 또는 메모리 펜스 명령어가 사용됩니다.

상호 배제 락, 예를 들어 std::mutex 또는 atomic spinlock 은 릴리스-어퀴어 동기화의 예시입니다: 스레드 A가 락을 릴리스하고 스레드 B가 어퀴어할 때, 스레드 A의 컨텍스트에서 크리티컬 섹션(릴리스 전)에서 발생한 모든 것은 동일한 크리티컬 섹션을 실행하는 스레드 B(어퀴어 후)에게 가시적이어야 합니다.

#include <atomic>
#include <cassert>
#include <string>
#include <thread>
std::atomic<std::string*> ptr;
int data;
void producer()
{
    std::string* p = new std::string("Hello");
    data = 42;
    ptr.store(p, std::memory_order_release);
}
void consumer()
{
    std::string* p2;
    while (!(p2 = ptr.load(std::memory_order_acquire)))
        ;
    assert(*p2 == "Hello"); // 절대 발생하지 않음
    assert(data == 42); // 절대 발생하지 않음
}
int main()
{
    std::thread t1(producer);
    std::thread t2(consumer);
    t1.join(); t2.join();
}

#include <atomic>
#include <cassert>
#include <thread>
#include <vector>
std::vector<int> data;
std::atomic<int> flag = {0};
void thread_1()
{
    data.push_back(42);
    flag.store(1, std::memory_order_release);
}
void thread_2()
{
    int expected = 1;
    // memory_order_relaxed is okay because this is an RMW,
    // and RMWs (with any ordering) following a release form a release sequence
    while (!flag.compare_exchange_strong(expected, 2, std::memory_order_relaxed))
    {
        expected = 1;
    }
}
void thread_3()
{
    while (flag.load(std::memory_order_acquire) < 2)
        ;
    // if we read the value 2 from the atomic flag, we see 42 in the vector
    assert(data.at(0) == 42); // will never fire
}
int main()
{
    std::thread a(thread_1);
    std::thread b(thread_2);
    std::thread c(thread_3);
    a.join(); b.join(); c.join();
}

릴리스-컨슘 순서화

#include <atomic>
#include <cassert>
#include <string>
#include <thread>
std::atomic<std::string*> ptr;
int data;
void producer()
{
    std::string* p = new std::string("Hello");
    data = 42;
    ptr.store(p, std::memory_order_release);
}
void consumer()
{
    std::string* p2;
    while (!(p2 = ptr.load(std::memory_order_consume)))
        ;
    assert(*p2 == "Hello"); // never fires: *p2 carries dependency from ptr
    assert(data == 42); // may or may not fire: data does not carry dependency from ptr
}
int main()
{
    std::thread t1(producer);
    std::thread t2(consumer);
    t1.join(); t2.join();
}

순차적 일관성 순서

memory_order_seq_cst 태그로 지정된 원자적 연산들은 릴리스/어quire 순서와 동일한 방식으로 메모리를 정렬할 뿐만 아니라(한 스레드에서 저장 연산 이전에 발생한 모든 것 이 로드를 수행한 스레드에서 가시적인 부수 효과 가 됨), 이렇게 태그된 모든 원자적 연산들의 단일 총 수정 순서 를 확립합니다.

// Thread 1:
x.store(1, std::memory_order_seq_cst); // A
y.store(1, std::memory_order_release); // B
// Thread 2:
r1 = y.fetch_add(1, std::memory_order_seq_cst); // C
r2 = y.load(std::memory_order_relaxed); // D
// Thread 3:
y.store(3, std::memory_order_seq_cst); // E
r3 = x.load(std::memory_order_seq_cst); // F

순차적 순서 지정은 모든 소비자가 모든 생산자의 동작이 동일한 순서로 발생하는 것을 관찰해야 하는 다중 생산자-다중 소비자 상황에서 필요할 수 있습니다.

전체 순차적 순서화는 모든 멀티코어 시스템에서 완전한 메모리 펜스 CPU 명령어를 필요로 합니다. 이는 영향을 받는 메모리 접근들이 모든 코어로 전파되도록 강제하기 때문에 성능 병목 현상이 될 수 있습니다.

#include <atomic>
#include <cassert>
#include <thread>
std::atomic<bool> x = {false};
std::atomic<bool> y = {false};
std::atomic<int> z = {0};
void write_x()
{
    x.store(true, std::memory_order_seq_cst);
}
void write_y()
{
    y.store(true, std::memory_order_seq_cst);
}
void read_x_then_y()
{
    while (!x.load(std::memory_order_seq_cst))
        ;
    if (y.load(std::memory_order_seq_cst))
        ++z;
}
void read_y_then_x()
{
    while (!y.load(std::memory_order_seq_cst))
        ;
    if (x.load(std::memory_order_seq_cst))
        ++z;
}
int main()
{
    std::thread a(write_x);
    std::thread b(write_y);
    std::thread c(read_x_then_y);
    std::thread d(read_y_then_x);
    a.join(); b.join(); c.join(); d.join();
    assert(z.load() != 0); // will never happen
}

volatile 과의 관계

실행 스레드 내에서, volatile glvalues 를 통한 접근(읽기 및 쓰기)은 동일한 스레드 내에서 sequenced-before 또는 sequenced-after 관계에 있는 관찰 가능한 사이드 이펙트(다른 volatile 접근 포함)를 기준으로 재배열될 수 없습니다. 그러나 이 순서는 volatile 접근이 스레드 간 동기화를 설정하지 않기 때문에 다른 스레드에서 관찰된다는 보장은 없습니다.

또한, volatile 접근은 원자적이지 않으며 (동시 읽기 및 쓰기는 data race 입니다) 메모리 순서를 정하지 않습니다 (비-volatile 메모리 접근들은 volatile 접근 주변에서 자유롭게 재정렬될 수 있습니다).

주목할 만한 예외는 Visual Studio로, 기본 설정에서는 모든 volatile 쓰기가 릴리스 의미를 가지고 모든 volatile 읽기가 획득 의미를 가집니다 ( Microsoft Docs ). 따라서 volatile 변수는 스레드 간 동기화에 사용될 수 있습니다. 표준 volatile 의미론은 다중 스레드 프로그래밍에 적용할 수 없지만, 동일한 스레드에서 실행되는 std::signal 핸들러와의 통신에는 sig_atomic_t 변수에 적용될 때 충분합니다. 컴파일러 옵션 /volatile:iso 를 사용하면 표준과 일관된 동작으로 복원할 수 있으며, 이는 대상 플랫폼이 ARM일 때 기본 설정입니다.

참고 항목

외부 링크