[Concurrency 07] Lock 선택 기준

Lock 선택 기준이란 임계 구역의 길이·경합 빈도·읽기 대 쓰기 비율 같은 워크로드 특성을 근거로 mutex, spinlock, shared_mutex, futex 기반 프리미티브 중 무엇을 쓸지 판단하는 체계를 말합니다. 실무에서는 “일단 mutex로 감싸고 느리면 spinlock으로 바꾼다"는 식의 시행착오가 흔한데, 이는 워크로드마다 최적 선택이 달라 매번 재현되는 비효율입니다. 이 장은 이전 장에서 정량화한 동기화 비용을 근거로, 어떤 신호를 보고 어떤 프리미티브를 고를지에 대한 재사용 가능한 기준을 세우는 데 목적이 있습니다.

이 장을 읽기 전에

이 장은 01장: 동기화 비용 정량 분석에서 측정한 “락 획득/해제·경합·컨텍스트 스위치 비용"의 크기를 전제로 합니다. mutex와 atomic 연산의 비용 차이, 그리고 경합이 왜 꼬리 지연(p99)을 악화시키는지를 먼저 이해하고 오면 이 장의 판단 기준이 훨씬 빠르게 와닿습니다. 이 장의 깊이는 기초 수준입니다 — mutex·spinlock·shared_mutex·futex의 동작 원리를 이해하고, 워크로드 신호(임계 구역 길이, 경합도, 읽기/쓰기 비율)로 프리미티브를 고르는 기준을 세우는 것이 목표입니다. 다루지 않는 것: cache line 배치와 false sharing 회피 기법은 03장, acquire/release 등 메모리 순서의 정확한 의미론은 04장, 락 없는 자료구조 설계는 05장, condition_variable의 성능 패턴은 19장, C++20 std::atomic::wait/notify의 futex 기반 구현 세부는 09장에서 각각 다룹니다.

당신의 수준에 맞는 경로

수준	읽을 부분	핵심 목표
초보자	“락의 계보” ~ “mutex의 내부 동작”	mutex가 futex 위에서 어떻게 동작하는지 이해
중급자	“spinlock” ~ “shared_mutex”	워크로드별로 spinlock·shared_mutex를 언제 쓸지 판단
실무 적용	“흔한 오개념” ~ “판단 기준”	자신의 코드에서 잘못 고른 락을 식별하고 교체

락의 계보: mutex에서 futex까지 (역사·배경)

POSIX 스레드 표준(IEEE Std 1003.1c, 1995)은 pthread_mutex_t를 정의했지만 구현 방식은 규정하지 않았습니다. 초기 Linux의 LinuxThreads 구현은 시그널 기반으로 스레드를 깨웠는데, 스레드 수가 늘어날수록 시그널 전달 비용이 커져 확장성이 나빴습니다. 2003년 Ulrich Drepper와 Ingo Molnar가 주도한 NPTL(Native POSIX Thread Library)이 리눅스 2.6 커널과 함께 도입되면서 futex(fast userspace mutex) 기반 구현으로 교체되었고, 이때부터 “무경합 상태에서는 커널에 진입하지 않는다"는 지금의 mutex 설계 원칙이 자리 잡았습니다. C++11(2011)은 이 플랫폼별 프리미티브를 std::mutex/std::lock_guard로 표준화해 이식 가능한 인터페이스를 제공했고, C++14는 std::shared_timed_mutex를, C++17은 타임아웃 기능을 뺀 경량 std::shared_mutex를 추가해 읽기 중심 워크로드를 표준 라이브러리만으로 다룰 수 있게 했습니다.

스핀락의 역사에는 반면교사 사례가 있습니다. Apple은 오랫동안 OSSpinLock을 저비용 락으로 제공했지만, 2015년경 커뮤니티에서 “높은 우선순위 스레드가 낮은 우선순위 스레드를 계속 선점해 스핀 중인 스레드가 영원히 락을 못 얻는” 우선순위 역전 문제가 널리 알려졌습니다. iOS의 스케줄러는 우선순위가 낮은 스레드에 실행 시간을 거의 배정하지 않을 수 있어, 스핀 중인 고우선순위 스레드가 그 낮은 스레드를 기다리며 사실상 멈추는 상황이 발생했습니다. 결국 OSSpinLock은 iOS 10(2016)에서 공식적으로 deprecated 처리되었고, 스핀하지 않고 커널에서 우선순위 역전을 방지하며 대기하는 os_unfair_lock으로 대체되었습니다. 이 사례는 “스핀락이 항상 더 빠르다"는 직관이 스케줄러·우선순위 조건에서 깨질 수 있음을 보여줍니다.

mutex의 내부 동작: futex 기반 fast/slow path

리눅스에서 std::mutex는 결국 pthread_mutex_t로, 이는 다시 futex(2) 시스템 콜 위에서 동작합니다. futex의 핵심 아이디어는 “무경합 구간은 전부 사용자 공간에서 원자적 연산만으로 끝내고, 실제로 대기가 필요한 경우에만 커널에 진입한다"는 것입니다. 락 상태를 나타내는 정수 하나를 원자적으로 조작해 성공하면 시스템 콜이 전혀 없고, 이미 잠겨 있어 실패한 스레드만 FUTEX_WAIT로 커널에 재워달라고 요청합니다. 아래는 이 로직을 단순화한 개념 스케치이며, 실제 glibc 구현은 재시도 횟수·스핀 등 추가 상태를 가진 3-상태 머신에 가깝습니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
lock():
  if compare_exchange(state, UNLOCKED, LOCKED):
    return                        // fast path: 원자적 CAS 성공, 시스템 콜 없음
  state = LOCKED_CONTENDED         // 경합 발생을 표시
  while not compare_exchange(state, UNLOCKED, LOCKED_CONTENDED):
    futex_wait(&state, LOCKED_CONTENDED)   // 값이 바뀔 때까지 커널이 재움(slow path)

unlock():
  if fetch_and_set(state, UNLOCKED) == LOCKED_CONTENDED:
    futex_wake(&state, 1)          // 대기자가 있었을 때만 한 명을 깨움(시스템 콜)

이 설계 덕분에 무경합 mutex의 lock/unlock은 원자적 CAS 한두 번에 그치고, 시스템 콜은 실제로 대기자가 있을 때만 발생합니다. 표준 std::mutex 자체는 어떤 재시도·스핀 전략을 쓸지 강제하지 않는 구현 정의(implementation-defined) 동작이며, Windows에서는 futex가 아니라 WaitOnAddress/SRWLOCK 계열 커널 프리미티브 위에서, macOS(libc++)에서는 os_unfair_lock 위에서 유사한 원칙으로 구현됩니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
#include <mutex>

class Counter {
 public:
  void increment() {
    std::lock_guard<std::mutex> lock(mutex_);  // RAII: 예외 발생 시에도 해제 보장
    ++value_;
  }
  long value() const {
    std::lock_guard<std::mutex> lock(mutex_);
    return value_;
  }

 private:
  mutable std::mutex mutex_;
  long value_ = 0;
};

std::lock_guard는 생성자에서 잠그고 소멸자에서 해제하므로 예외가 발생해도 락이 풀립니다. 다만 락을 쥔 채로 값비싼 연산(I/O, 다른 락 획득)을 하지 않도록 임계 구역을 최소화하는 것이 우선이며, 그 판단은 01장의 비용 측정과 짝을 이룹니다.

spinlock: 언제 유리한가

spinlock은 락을 못 얻으면 커널에 넘기지 않고 사용자 공간에서 원자적 연산을 반복(busy-wait)하며 재시도하는 방식입니다. 컨텍스트 스위치 비용(커널 진입, 스케줄러 큐 조작, 캐시 워밍업 재현)을 아예 지불하지 않으므로, 임계 구역이 매우 짧고(수십–수백 ns) 다른 코어가 곧 락을 풀어줄 것이 거의 확실할 때 mutex보다 유리할 수 있습니다. 반대로 대기 시간이 길어질 조건(선점, 단일 코어, 코어보다 스레드가 많은 상황)에서는 CPU 사이클만 태우고 아무 진전이 없으므로 손해가 큽니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
#include <atomic>
#include <thread>

class SpinLock {
 public:
  void lock() noexcept {
    while (flag_.test_and_set(std::memory_order_acquire)) {
      while (flag_.test(std::memory_order_relaxed)) {  // C++20: test로 캐시 라인만 폴링
        std::this_thread::yield();  // 과도한 스핀 시 스케줄러에 양보
      }
    }
  }
  void unlock() noexcept { flag_.clear(std::memory_order_release); }

 private:
  std::atomic_flag flag_ = ATOMIC_FLAG_INIT;
};

test_and_set 자체가 캐시 라인을 배타적으로 가져오는(RFO) 연산이므로, 안쪽 루프에서 매번 test_and_set을 재시도하면 코어 간 캐시 라인 핑퐁이 심해집니다. 그래서 바깥은 test_and_set, 안쪽 재시도는 읽기 전용 test(또는 C++20 이전이라면 load)로 폴링하는 test-and-test-and-set 패턴을 씁니다 — 캐시 라인 경합과 정렬 문제는 03장에서 더 깊이 다룹니다. glibc는 이 절충을 표준 mutex 안에도 부분적으로 들여왔습니다: PTHREAD_MUTEX_ADAPTIVE_NP 확장으로 만든 mutex는 즉시 잠들지 않고 glibc.pthread.mutex_spin_count 튜너블(기본값 100회)만큼 먼저 스핀한 뒤에야 futex로 블로킹합니다. 단, 이는 GNU 확장이며 표준 std::mutex가 자동으로 적용하는 동작이 아닙니다.

shared_mutex와 읽기 중심 워크로드

std::shared_mutex(C++17)는 읽기(shared) 잠금과 쓰기(exclusive) 잠금을 구분합니다. 여러 리더가 동시에 shared 잠금을 보유할 수 있고, 라이터가 exclusive 잠금을 요청하면 모든 리더가 빠질 때까지 기다립니다. 읽기가 압도적으로 많고 쓰기가 드문 캐시·설정 테이블 같은 자료구조에서, 순수 mutex는 리더끼리도 서로 직렬화시켜 처리량을 깎아 먹지만 shared_mutex는 리더들을 병렬로 흘려보낼 수 있습니다. Windows의 대응물인 SRWLOCK도 같은 shared/exclusive 모드를 제공하며 공식 문서는 “읽기가 쓰기보다 많으면 이 동시성이 critical section 대비 성능·처리량을 높인다"고 설명합니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
#include <shared_mutex>
#include <string>
#include <unordered_map>

class ConfigCache {
 public:
  std::string get(const std::string& key) const {
    std::shared_lock lock(mutex_);        // 여러 리더가 동시에 보유 가능
    auto it = map_.find(key);
    return it != map_.end() ? it->second : std::string{};
  }
  void set(std::string key, std::string value) {
    std::unique_lock lock(mutex_);        // 단독 라이터, 모든 리더 배제
    map_[std::move(key)] = std::move(value);
  }

 private:
  mutable std::shared_mutex mutex_;
  std::unordered_map<std::string, std::string> map_;
};

shared_mutex는 리더 수 관리를 위한 추가 상태(리더 카운트, 대기 큐)를 가지므로 무경합 상태에서도 순수 mutex보다 lock/unlock 오버헤드가 크며, 구현에 따라 라이터가 계속 도착하면 리더가 굶거나(reader starvation) 반대로 리더가 몰리면 라이터가 굶는(writer starvation) 정책 차이가 있습니다. 읽기 비율이 낮거나 임계 구역이 매우 짧다면 이 오버헤드가 병렬성 이득을 상쇄해 순수 mutex보다 오히려 느려질 수 있으므로, “읽기/쓰기 비율이 실제로 리더 편중인가"를 먼저 확인해야 합니다.

흔한 오개념

“spinlock은 항상 mutex보다 빠르다”는 임계 구역이 짧고 코어가 남아돌며 스레드 수가 코어 수를 넘지 않는다는 전제가 있을 때만 성립합니다. 스레드가 코어보다 많거나 스핀 중에 선점되면, 락을 쥔 스레드가 실행되지 못하는 동안 다른 스레드들은 CPU만 태우며 아무 진전도 만들지 못합니다 — OSSpinLock이 결국 폐기된 이유가 이 실패 모드였습니다.

"std::mutex는 기본적으로 adaptive spin을 쓴다”도 흔한 오해입니다. glibc의 adaptive spin은 PTHREAD_MUTEX_ADAPTIVE_NP 타입으로 명시적으로 만든 mutex에만 적용되는 비표준 GNU 확장이며, std::mutex가 내부적으로 사용하는 pthread mutex 타입은 이 확장을 자동으로 켜지 않습니다. 스핀 후 블로킹 전환을 원한다면 라이브러리가 직접 그렇게 구현했는지 표준 문서가 아니라 구현 소스로 확인해야 합니다.

“shared_mutex로 바꾸면 항상 이득”이라는 가정도 위험합니다. 앞서 본 것처럼 무경합 lock/unlock 자체의 오버헤드가 순수 mutex보다 크고, 쓰기가 자주 섞이거나 임계 구역이 짧으면 병렬 읽기의 이득보다 관리 비용이 커질 수 있습니다. 바꾸기 전에 실제 읽기/쓰기 비율과 임계 구역 길이를 먼저 측정하는 것이 순서입니다.

판단 기준

아래 표는 워크로드 신호별 1차 권장안입니다. 정확한 임계값(예: “몇 ns 이하면 스핀”)은 코어 수, 스케줄러, 컴파일러·플래그에 따라 달라지므로, 표는 출발점으로 삼고 실제 결정은 자신의 워크로드에서 측정한 뒤에 내려야 합니다.

워크로드 신호	권장	비권장인 이유
임계 구역 매우 짧음(수십–수백 ns) + 코어 여유 있음 + 스레드 수 ≤ 코어 수	spinlock 또는 adaptive mutex	순수 mutex는 블로킹 전환(커널 진입) 오버헤드가 상대적으로 큼
임계 구역 길거나 가변적, 또는 대기 시간이 길어질 수 있음	`std::mutex`(futex 기반)	spinlock은 대기 중 CPU만 소비하고 진전이 없음
읽기 압도적, 쓰기 드묾	`std::shared_mutex`/`SRWLOCK`	순수 mutex는 리더끼리도 직렬화되어 처리량 손실
쓰기 비중이 높거나 임계 구역이 매우 짧음	`std::mutex`	shared_mutex의 리더 카운트 관리 오버헤드가 병렬 이득을 상쇄
스레드 수가 코어 수를 초과(오버서브스크립션)	`std::mutex`(블로킹)	spinlock은 선점된 락 보유자를 기다리며 다른 스레드까지 낭비
실시간·우선순위 역전에 민감	우선순위 상속 지원 mutex(`PTHREAD_PRIO_INHERIT`) 또는 재설계	일반 spinlock·adaptive mutex는 우선순위 역전에 취약

경합·대기 시간이 실제로 지배항인지 확신이 서지 않으면, 락 종류를 바꾸기 전에 01장에서 다룬 방식으로 먼저 측정해야 합니다. 아래는 임계 구역 보유 시간을 직접 계측해 후보 락을 좁히는 최소 벤치마크 스켈레톤입니다(x86-64 Linux, GCC 13, g++ -O2 -std=c++20 bench.cpp -lbenchmark -lpthread -o bench로 빌드).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
#include <benchmark/benchmark.h>
#include <mutex>

std::mutex g_mutex;
long g_counter = 0;

static void BM_MutexIncrement(benchmark::State& state) {
  for (auto _ : state) {
    std::lock_guard<std::mutex> lock(g_mutex);
    ++g_counter;                       // 실제 임계 구역과 비슷한 작업으로 교체해 측정
  }
}
BENCHMARK(BM_MutexIncrement)->Threads(1)->Threads(4)->Threads(16);

BENCHMARK_MAIN();

--benchmark_repetitions=5 --benchmark_report_aggregates_only=true 옵션으로 스레드 수를 늘려가며 반복 실행하면, 스레드 수 증가에 따라 처리량이 어디서 꺾이는지가 드러납니다. 같은 스켈레톤에서 std::mutex를 위의 SpinLock으로 교체해 비교하면 자신의 코어 수·워크로드에서 어느 쪽이 유리한지 직접 확인할 수 있습니다.

flowchart TD
  csLen{"임계 구역 길이·경합"}
  csLen -->|"매우 짧음 + 코어 여유"| contended{"스레드 수가
코어 수 이하인가?"}
  csLen -->|"길거나 가변적"| rwRatio{"읽기:쓰기 비율은?"}
  contended -->|"예"| useSpin["spinlock 또는
adaptive mutex"]
  contended -->|"아니오(오버서브스크립션)"| useMutex["std::mutex(futex 기반)"]
  rwRatio -->|"읽기 압도적"| useShared["std::shared_mutex / SRWLOCK"]
  rwRatio -->|"쓰기 비중 높음"| useMutex

비판적 시각: 한계와 트레이드오프

C++ 표준은 std::mutex·std::shared_mutex의 내부 알고리즘(스핀 여부, 페어니스, 우선순위 처리)을 규정하지 않으므로, 같은 코드라도 libstdc++·libc++·MSVC STL에서 서로 다른 성능 특성을 보일 수 있습니다. glibc의 mutex_spin_count 같은 튜너블은 Linux에서만 존재하는 비표준 확장이라 이식성이 없고, 컨테이너·가상화 환경에서는 코어 수 인식 자체가 달라져 스핀 전략의 효과가 베어메탈과 다르게 나타날 수 있습니다. shared_mutex/SRWLOCK의 리더-라이터 공정성 정책도 구현마다 달라, “리더 편중 워크로드에는 무조건 유리하다"는 가정은 라이터 기아 현상이 실제로 문제가 되는 시스템에서는 성립하지 않을 수 있습니다. 이런 이유로 이 장의 판단표는 출발점일 뿐이며, 실제 배포 전에는 대상 플랫폼·컴파일러·코어 구성에서 재현 가능한 벤치마크로 확인하는 절차가 필요합니다.

마무리

futex 기반 mutex의 fast path(무경합, 시스템 콜 없음)와 slow path(대기, FUTEX_WAIT/FUTEX_WAKE)를 구분해 설명할 수 있다.
spinlock이 유리한 조건(짧은 임계 구역, 코어 여유, 오버서브스크립션 없음)과 위험한 조건(선점, 단일 코어, 우선순위 역전)을 구분할 수 있다.
std::shared_mutex/SRWLOCK이 읽기 중심 워크로드에서 이득을 주는 조건과, 오히려 손해가 되는 조건을 설명할 수 있다.
“spinlock이 항상 빠르다”, “std::mutex는 기본으로 adaptive spin을 쓴다”, “shared_mutex는 항상 이득"이라는 세 가지 오개념을 교정할 수 있다.
자신의 워크로드에서 임계 구역 길이·경합도·읽기/쓰기 비율을 근거로 mutex·spinlock·shared_mutex 중 하나를 선택하고, 벤치마크로 그 선택을 검증할 수 있다.

다음 장에서는 이번 장에서 다룬 spinlock의 test-and-test-and-set 패턴이 왜 캐시 라인 배치에 민감한지를 더 깊이 파고듭니다. 여러 스레드가 논리적으로 무관한 변수를 같은 캐시 라인에서 공유할 때 생기는 false sharing을 탐지하는 도구와, 이를 회피하는 정렬·패딩 기법을 다룹니다.

→ False Sharing 탐지와 회피