85 쪼개지지 않는 연산 — <stdatomic.h>

85.1 잃어버린 갱신 — 눈으로 확인한다#

/* 경쟁 상태와 원자적 연산 — 같은 프로그램을 두 번 돌린다. */
#include <stdatomic.h>
#include <stdio.h>
#include <threads.h>

#define THREADS 4
#define BUMPS   200000

static long        plain;   /* 그냥 long — 보호 없음 */
static atomic_long safe;    /* 원자적 long        */

static int worker(void *unused)
{
    (void)unused;
    for (int i = 0; i < BUMPS; i++) {
        plain = plain + 1;                    /* 읽고-더하고-쓰기: 쪼개진다 */
        atomic_fetch_add(&safe, 1);           /* 한 덩어리로 일어난다      */
    }
    return 0;
}

int main(void)
{
    thrd_t t[THREADS];

    for (int i = 0; i < THREADS; i++)
        thrd_create(&t[i], worker, NULL);
    for (int i = 0; i < THREADS; i++)
        thrd_join(t[i], NULL);

    long expected = (long)THREADS * BUMPS;
    printf("expected  : %ld\n", expected);
    printf("unprotected: %ld%s\n", plain, plain == expected ? "" : "  <- we lost some");
    printf("atomic    : %ld\n", (long)safe);

    printf("\nis atomic_long lock-free? %s\n",
           atomic_is_lock_free(&safe) ? "yes" : "no");
    return 0;
}

expected  : 800000
unprotected: 278076  <- we lost some
atomic    : 800000

is atomic_long lock-free? yes

같은 루프를 네 갈래가 20만 번씩 돌았다. 기대한 값은 80만인데, 보호 없는 long은 그 근처에도 못 갔다. 사라진 몫은 실행할 때마다 다르다 — 이 비결정성이야말로 이 부류 버그의 성격이다. 재현되지 않는 손실.

원자적(atomic) 변수 쪽은 언제나 정확히 80만이다. atomic_fetch_add가 “읽고-더하고-쓰기”를 쪼개질 수 없는 한 덩어리로 수행하기 때문이다. 원자(原子)라는 이름이 그 뜻이다 — 더 이상 쪼개지지 않는 것.

85.2 volatile은 왜 답이 아닌가#

C를 오래 쓴 코드에서 volatile int flag;로 갈래 사이 신호를 주고받는 관행을 자주 본다. 지금은 틀린 관행이다. volatile이 약속하는 것은 하나 뿐이다 — 컴파일러가 이 접근을 없애거나 합치지 않는다. 54장에서 볼 대로 그 목적은 하드웨어 레지스터(값이 바깥에서 바뀌는 자리)였다.

volatile이 약속하지 않는 것이 둘이다. 원자성 — volatile long x;의 x++도 여전히 세 걸음이라 쪼개진다. 그리고 순서와 가시성 — CPU가 쓰기 순서를 바꾸거나 다른 코어에 늦게 보이는 것을 막지 못한다.

정리하면 이렇다. 하드웨어 레지스터에는 volatile, 갈래 사이 공유에는 원자적 타입이나 뮤텍스. 자바나 C#의 volatile은 이름만 같고 의미가 달라서(그쪽은 실제로 가시성을 보장한다), 그 언어의 습관을 C로 들여오는 것이 흔한 사고의 통로다.

85.3 원자적 타입과 연산#

쓰는 법은 단순하다. 타입 앞에 _Atomic을 붙이거나, 헤더가 주는 이름 (atomic_int, atomic_long, atomic_bool, atomic_size_t …)을 쓴다.

#include <stdatomic.h>
atomic_int  counter = 0;      /* = _Atomic int */
_Atomic long total;

연산은 함수(또는 그 이름의 매크로)로 부른다. 평범한 연산자(++, +=)를 써도 원자적으로 동작하지만, 원자적이라는 사실이 코드에 보이지 않아 읽는 사람이 놓치기 쉬우므로 명시적 함수를 권한다.

fetch_add가 이전 값을 돌려준다는 점이 자주 헷갈리는 자리다. “몇 번째 인지”를 얻고 싶으면 반환값을 쓰고, “지금 얼마인지”를 알고 싶으면 반환값에 더한 값이거나 별도의 atomic_load다 — 그런데 후자는 그사이 또 바뀔 수 있다.

85.3.1 CAS — 「그대로면 바꿔라」#

fetch_add 같은 연산은 「더하기」라는 정해진 갱신만 해 준다. 그런데 실무의 갱신은 대개 조건이 붙는다 — 「한도를 넘지 않으면 올려라」, 「지금 값보다 크면 바꿔라」, 「이 상태일 때만 다음 상태로 넘겨라」. 이런 것은 읽고 → 판단하고 → 쓰기의 세 걸음이고, 그 사이에 남이 끼어들 수 있다.

그래서 나온 것이 비교 교환(CAS, compare-and-swap)이다. 발상은 한 문장이다.

내가 읽었던 값이 아직 그대로면 바꿔라. 아니면 바꾸지 말고 알려 달라.

C 의 이름은 atomic_compare_exchange_strong(과 _weak)이고, 계약은 이렇다.

bool atomic_compare_exchange_strong(A *object, C *expected, C desired);

• object 의 현재 값이 *expected 와 같으면 — desired 를 넣고 true 를 준다.
• 다르면 — 아무것도 바꾸지 않고 false 를 주되, ★ *expected 에 현재 값을 적어 준다(§7.17.7.4 p3).

둘째 줄의 「적어 준다」가 이 함수의 모양을 정한다. 실패했을 때 최신 값이 손에 들어오므로, 다시 읽을 필요 없이 그대로 다시 시도하면 된다. 그래서 CAS 는 거의 언제나 루프로 쓰인다.

int cur = atomic_load(&x);
int next;
do {
    next = f(cur);                                     /* 어떤 갱신 규칙이든 */
} while (!atomic_compare_exchange_weak(&x, &cur, next));

★ 이 다섯 줄이 CAS 가 만능 도구인 이유다. f 자리에 무엇을 넣든 — 조건부 증가든, 최댓값 갱신이든, 상태 기계의 전이든 — 그 갱신이 원자적으로 이뤄진다. 실제로 fetch_add 조차 이 루프로 만들 수 있다(하드웨어가 직접 해 주니 그럴 이유가 없을 뿐).

둘째 줄이 바로 아래 문답의 「가짜 실패」다. 예약은 값이 아니라 그 자리에 걸리므로, 다른 코어가 같은 캐시 줄을 건드리거나 인터럽트가 한 번 끼어들기만 해도 풀린다.

if (atomic_load(&count) < LIMIT)      /* ① 읽고 */
    atomic_fetch_add(&count, 1);      /* ② 더한다 — 그사이 남이 끼어든다 */

int cur = atomic_load(&count);
do {
    if (cur >= LIMIT) break;                 /* 한도 검사와 갱신을 한 덩어리로 */
} while (!atomic_compare_exchange_weak(&count, &cur, cur + 1));

85.4 메모리 순서 — 건드리지 않는 것이 기본#

85.4.1 왜 「순서」가 문제가 되는가#

원자성은 「쪼개지지 않음」이었다. 순서는 다른 질문이다 — 내가 적은 차례대로 남들이 보는가.

답은 「아니다」이고, 순서를 바꾸는 범인이 둘이다.

1. 컴파일러가 바꾼다. 한 갈래만 놓고 보면 결과가 같으니 더 빠른 차례로 옮겨 적는다 (14장의 편집자).
2. CPU 도 바꾼다. 쓰기를 버퍼에 모았다가 내보내고, 준비된 명령부터 먼저 실행한다 (13장).

둘 다 혼자 도는 프로그램에게는 들키지 않는다. 자기가 쓴 값은 자기가 제대로 읽으니까. 문제는 옆에서 다른 갈래가 볼 때 드러난다.

그림 85.1 — 깃발이 보이면 그 앞의 데이터도 보이는가.

그림 85.1이 그 상황이다. 쓰는 쪽은 자료를 채우고 깃발을 세운다. 읽는 쪽은 깃발을 보고 자료를 읽는다. 사람의 눈에는 당연해 보이는데, 순서를 묶지 않으면 깃발이 자료보다 먼저 도착할 수 있다. 그러면 읽는 쪽은 「준비됐다」는 신호를 보고도 준비되기 전의 값을 읽는다.

85.4.2 짝이 벽을 세운다 — release 와 acquire#

그래서 짝을 쓴다. 쓰는 쪽은 깃발을 release 로 세우고, 읽는 쪽은 깃발을 acquire 로 읽는다.

/* 쓰는 쪽 */                          /* 읽는 쪽 */
data = 42;                             if (atomic_load_explicit(
atomic_store_explicit(                       &flag, memory_order_acquire)) {
    &flag, 1, memory_order_release);       use(data);     /* 42 임이 보장된다 */
                                       }

두 낱말의 뜻은 방향이다. release 는 「앞의 쓰기들이 이 지점 아래로 내려가지 못한다」, acquire 는 「뒤의 읽기들이 이 지점 위로 올라가지 못한다」. 한쪽만 세우면 소용이 없다 — 벽은 두 쪽이 짝을 이룰 때 선다.

★ 그리고 이 짝이 보장하는 것은 깃발 하나가 아니다. 깃발이 보이면 그 앞에 쓴 모든 것이 함께 보인다. 그래서 자료 자체는 원자적일 필요가 없다 — 위 코드에서 data 는 그냥 int 다.

85.4.3 순서는 공짜인가 — 재어 본다#

「가장 비싸다」는 말은 얼마나 비싸다는 뜻인가. 같은 C 코드를 두 기계로 컴파일해 보면 답이 눈에 보인다.

★ 첫 줄과 둘째 줄이 x86 에서 글자 하나 다르지 않다. 그 기계가 이미 그 순서를 지키기 때문이다. 여기서 이 장의 가장 실질적인 경고가 나온다 — relaxed 로 잘못 쓴 코드는 x86 에서 시험하면 멀쩡히 돈다. 같은 코드가 RISC-V·ARM 에서는 fence 가 빠진 채로 돌아 재현되지 않는 버그가 된다.

셋째 줄은 두 기계 모두에서 값을 치른다. 기본값이 안전한 대신 비싼 이유가 이것이다.

atomic_fetch_add(&x, 1)처럼 순서를 지정하지 않으면 가장 강한 순서인 순차 일관성(memory_order_seq_cst)이 쓰인다. 모든 갈래가 원자적 연산의 순서를 하나의 일관된 이야기로 본다는 뜻이고, 사람이 추론하기 가장 쉬운 모형이다. 대신 가장 비싸다.

C 에는 여섯 가지 순서가 있다. 표로 얼굴만 익힌다 — 대부분의 프로그램은 기본값만 쓰면 된다.

가장 흔한 실전 쓰임은 두 가지다. 첫째, 생산자-소비자의 깃발: 데이터를 채운 뒤 release로 깃발을 세우고, 소비자는 acquire로 깃발을 본 뒤 데이터를 읽는다. 이 짝이 “깃발이 보이면 데이터도 보인다”를 보장 한다. 둘째, 순수 통계 카운터: 값의 최종 합만 맞으면 되고 다른 데이터와 순서를 맞출 필요가 없으므로 relaxed가 정확히 맞는 도구다.

atomic_store_explicit(&ready, 1, memory_order_relaxed);   /* 깃발 */

85.5 잠금 없음(lock-free)이라는 말#

예제 마지막 줄이 atomic_is_lock_free로 물은 것이 그것이다. 원자적 타입이 CPU 명령 하나로 처리되면 잠금 없음이고, 그렇지 않으면 라이브러리가 뒤에서 숨은 잠금을 쓴다. 오늘의 주류 기계에서 포인터 크기 이하의 정수는 대개 잠금 없이 된다. 반면 큰 구조체를 _Atomic으로 감싸면 — 문법은 통과하지만 — 숨은 잠금이 붙어 성능이 뜻밖에 나빠질 수 있다.

85.6 쓸 자리와 쓰지 않을 자리#

85.7 자물쇠를 쥔 쪽이 멈추면 — 우선순위 역전과 스핀락#

원자적 연산이 답이 아닌 자리에서는 결국 자물쇠를 쓴다. 그런데 자물쇠에는 원자성과는 다른 종류의 위험이 하나 있다. 자물쇠를 쥔 쪽이 일을 못 하게 되는 것이다.

=== 우선순위 역전 — 낮은 쪽이 높은 쪽을 막는다

셋이 있다고 하자. 급한 일(높은 우선순위), 보통 일(중간), 한가한 일(낮은).

1. 한가한 일이 자물쇠를 잡는다.
2. 급한 일이 깨어나 같은 자물쇠를 달라고 한다 — 막힌다. 여기까지는 정상이다.
3. 그런데 보통 일이 깨어나 한가한 일을 밀어낸다. 우선순위가 높으니까.
4. 이제 한가한 일은 돌지 못하고, 자물쇠를 놓지 못하고, 급한 일은 계속 막혀 있다.

결과가 이상하다. 급한 일이 자기보다 낮은 「보통 일」에게 밀린 셈이 된다. 이것을 우선순위 역전(priority inversion)이라 한다. 자물쇠가 잘못된 것도, 원자성이 깨진 것도 아니다 — 우선순위와 자물쇠라는 두 규칙이 만나 서로를 무너뜨린 것이다.

처방은 「쥔 쪽을 끌어올리는」 것이다. 우선순위 상속(priority inheritance)은 급한 일이 막히는 순간 자물쇠를 쥔 쪽의 우선순위를 급한 일만큼 올려 준다. 그러면 보통 일이 밀어내지 못하고, 쥔 쪽이 빨리 끝내고 놓는다.

85.7.1 같은 병의 다른 얼굴 — 사용자 공간의 스핀락#

스핀락(spinlock)은 자물쇠가 열릴 때까지 잠들지 않고 돌며 기다리는 자물쇠다. 임계 구역이 아주 짧을 때는 잠들었다 깨는 비용보다 싸서 이긴다. 그 계산은 하나의 가정 위에 서 있다 — 쥔 쪽이 그사이에 쫓겨나지 않는다.

커널 안에서는 그 가정을 지킬 수 있다. 선점을 잠깐 끄면 된다. 사용자 공간에는 그런 장치가 없다. 쥔 쪽이 스케줄러에 밀려나면, 기다리는 쪽 전부가 아무 진전 없이 CPU를 태운다. 우선순위 역전과 뿌리가 같다 — 쥔 쪽이 멈추는 것이다.

쪼개지지 않는 연산을 보았다. 다음 장은 정반대 방향의 도구다 — 연산이 그릇을 넘쳤는지를 계약대로 물어보는, C23의 검사 산술이다.