모범답안 — 메모리 배리어와 약한 메모리 모델 심화

난이도: 최상

핵심 답변

메모리 재배열은 컴파일러 최적화와 CPU의 비순차 실행/스토어 버퍼 두 층에서 일어난다. x86은 강한 모델(TSO)이라 store→load 외엔 재배열이 거의 없어 버그가 우연히 숨지만, ARM은 약한 모델이라 로드/스토어가 자유롭게 재배열돼 같은 코드가 깨진다. 해법은 memory_order로 acquire/release 짝을 만들어 "한 스레드의 release 저장 이전 쓰기들이, 그 값을 acquire로 읽은 스레드에 보인다"는 happens-before를 강제하는 것이다.

깊이 있는 설명

재배열의 두 층위

컴파일러: 의존성이 없다고 판단하면 명령 순서를 바꾸거나 변수를 레지스터에 캐싱한다. → 컴파일러 배리어/atomic으로 막음.
CPU: 비순차 실행, 스토어 버퍼(쓰기를 모았다 나중에 메모리 반영), 캐시 등으로 다른 코어가 보는 순서가 프로그램 순서와 다를 수 있다.

강/약 메모리 모델

x86 (TSO): 대부분의 재배열을 금지. 허용되는 건 사실상 "이전 store가 이후 load를 추월당하는" 케이스 정도. 그래서 배리어가 부족한 코드도 자주 우연히 동작.
ARM/POWER (약한 모델): 의존성 없는 로드/스토어를 광범위하게 재배열. 배리어를 명시하지 않으면 다른 코어가 오래된 값·뒤바뀐 순서를 본다 → "x86 OK, ARM 깨짐".

memory_order

relaxed: 원자성만 보장, 순서 보장 없음(단순 카운터 등).
release(저장): 이 저장 이전의 모든 쓰기가 이 저장보다 앞서도록 고정.
acquire(로드): 이 로드 이후의 모든 읽기/쓰기가 이 로드보다 뒤에 오도록 고정.
release–acquire 짝: A 스레드가 release로 데이터 준비 후 플래그 저장 → B가 그 플래그를 acquire로 읽으면, 플래그 저장 전 A의 모든 쓰기가 B에 보인다(synchronizes-with → happens-before).
seq_cst: 모든 seq_cst 연산에 단일 전역 순서까지 보장(가장 강하고 가장 비쌈, 기본값).

C# 대응

Volatile.Read≈acquire, Volatile.Write≈release 의미. volatile 키워드도 유사한 acquire/release 의미를 부여(C# 메모리 모델 기준).
Interlocked.*는 원자적 RMW + 전체 배리어(full fence)에 준하는 순서 보장.
C#은 CLR이 비교적 강한 모델을 보장해 C++보다 함정이 적지만, volatile 없는 단순 필드 공유는 여전히 가시성/재배열 위험.

응용/실무 연결

lock-free 큐/플래그(SPSC 등): 데이터 쓰기는 평범하게, 발행 인덱스/플래그만 release로 쓰고 소비자는 acquire로 읽어 happens-before 성립.
멀티플랫폼(ARM 서버, 모바일) 빌드는 x86에서만 테스트하면 안 됨 — TSan/스트레스 테스트로 약한 모델 가정 검증.

흔한 오답·함정

"x86에서 통과했으니 정상" — 약한 모델에서 깨질 수 있다. 정확성은 메모리 모델로 논증해야지 테스트만으론 부족.
모든 걸 seq_cst로 — 정확하지만 느리다. 핫패스는 relaxed/acq-rel로 최소 배리어.
volatile(C++)이 스레드 동기화 도구라는 오해 — C++의 volatile은 메모리맵 IO용이지 스레드 동기화 보장이 아니다. std::atomic을 써야 한다.

꼬리질문 대비