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

80.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: 288229  <- we lost some
atomic    : 800000

is atomic_long lock-free? yes

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

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

80.2 volatile은 왜 답이 아닌가

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

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

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

80.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다 — 그런데 후자는 그사이 또 바뀔 수 있다.

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));

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

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

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

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

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

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

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

80.6 쓸 자리와 쓰지 않을 자리

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