Spinlocks vs. Mutexes: 언제 스핀하고 언제 슬립할까

Source: Hacker News

소개

perf top에서 pthread_mutex_lock이 60 % CPU 시간을 차지하고 있는 모습을 보고 있습니다. 레이턴시는 끔찍합니다. 누군가 “그냥 스핀락을 써라”고 제안하자, 16코어 서버가 아무 일도 하지 않으면서 100 %에 달합니다. 이것이 동기화 원시(primitives) 함정입니다: 엔지니어들은 각 원시가 언제 의미가 있는지 이해하지 못해 잘못된 선택을 하는 경우가 많습니다.

스핀락 vs. 뮤텍스

언제 어떤 원시를 사용할까

프로파일링 팁

• CPU vs. 컨텍스트 스위치 – 다음 명령 실행:

  perf stat -e context-switches,cache-misses 

  • CPU 사용량은 낮지만 컨텍스트 스위치가 많으면 → 뮤텍스 오버헤드가 지배적일 수 있습니다.
  • CPU 100 %에 캐시 미스가 많으면 → 락 경쟁 / 잘못된 공유 가능성.

• 시스템 콜 횟수 – strace -c 로 futex() 호출을 셉니다. 초당 수백만 건이면 경쟁이 심한 락이며, 샤딩이나 락‑프리 기법을 고려할 수 있습니다.

• 자발적 vs. 비자발적 스위치 – /proc/<pid>/status 를 확인합니다. 스핀락을 보유한 상태에서 비자발적 스위치가 발생하면 선점 문제를 나타냅니다.

실제 사례

• Redis – 작은 작업 큐(임계 구역)에서 스핀락을 사용합니다.

  #include <pthread.h>
  #include <stdatomic.h>
  
  #define NUM_THREADS   4
  #define ITERATIONS    1000000
  #define HOLD_TIME_NS  100   // simulated work
  
  typedef struct {
      atomic_int lock;
      long       counter;
  } spinlock_t;
  
  static void spinlock_acquire(spinlock_t *s) {
      int expected;
      do {
          expected = 0;
      } while (!atomic_compare_exchange_weak(&s->lock, &expected, 1));
  }
  
  static void spinlock_release(spinlock_t *s) {
      atomic_store(&s->lock, 0);
  }
  
  static void *worker_thread(void *arg) {
      spinlock_t *s = (spinlock_t *)arg;
      for (long i = 0; i < ITERATIONS; i++) {
          spinlock_acquire(s);
          s->counter++;
          /* Simulate ~100 ns of work */
          for (volatile int j = 0; j < HOLD_TIME_NS; j++) {
              // busy‑wait
          }
          spinlock_release(s);
      }
      return NULL;
  }

삽화