스핀락(Spinlock) 사용, CPU를 태울 수 있다!

게시물에서는 기본적인 스핀락 구현의 문제점을 지적하며, 원자적 연산(Atomic Operations)을 사용하지 않으면 레이스 컨디션(Race Condition)이 발생할 수 있다고 경고한다. 특히, `isLocked` 변수를 `int32_t`로 선언하고, 여러 스레드에서 동시에 접근할 경우 데이터 무결성(Data Integrity)이 깨질 수 있음을 강조한다. 또한, `exchange` 연산을 통해 원자성을 보장하는 방법을 제시하며, 올바른 스핀락 구현의 중요성을 강조한다.

저자는 스핀락이 CPU 자원을 낭비하는 주요 원인으로, 빈 루프(Empty Loop)를 돌면서 CPU 주파수를 높게 유지하는 점을 지적한다. 이를 해결하기 위해 PAUSE 명령어를 사용하여 CPU의 과도한 자원 사용을 막고, 메모리 접근 시 발생하는 성능 저하(Performance Degradation)를 완화해야 한다고 설명한다. 또한, 백오프(Backoff) 전략을 통해 PAUSE 명령어의 실행 횟수를 조절하여 성능을 최적화하는 방법을 제시한다.

게시물은 스핀락 사용 시 발생할 수 있는 우선순위 역전(Priority Inversion) 문제를 심각하게 다루며, 이로 인해 고우선순위 스레드가 무한정 CPU 자원을 소모하는 상황을 설명한다. 해결책으로 OS의 WaitOnAddress 또는 futex API를 사용하여 스레드를 대기 상태로 만들고, CPU 사용률(CPU Utilization)을 효율적으로 관리하는 방법을 제시한다. 또한, .NET 런타임의 Sleep(1) 사용에 대한 문제점을 지적하며, OS 프리미티브의 중요성을 강조한다.

저자는 스핀락에서 메모리 정렬(Memory Alignment)과 캐시 라인(Cache Line) 문제를 언급하며, 여러 변수가 동일한 캐시 라인을 공유할 경우 발생하는 성능 저하를 설명한다. 이를 해결하기 위해 `std::hardware_destructive_interference_size`를 사용하여 변수를 정렬하고, False Sharing 문제를 완화하는 방법을 제시한다. 하지만, 이 방법이 TLB 및 L1 캐시를 과도하게 채울 수 있다는 점도 함께 지적하며, 트레이드오프(Trade-offs)를 고려해야 함을 강조한다.