[synchronization] 언제 mutex 대신 spinlock을 사용해야합니까?

이론

이론적으로 스레드가 뮤텍스를 잠그려고 시도하고 성공하지 못하면 뮤텍스가 이미 잠겨 있기 때문에 잠자기 상태가되어 즉시 다른 스레드를 실행할 수 있습니다. 그것은 깨어날 때까지 계속 잠 들어 있는데, 이것은 이전에 잠금 장치를 잡고 있던 스레드에 의해 뮤텍스가 잠금 해제되는 경우입니다. 스레드가 spinlock을 잠그려고 시도하고 실패하면 마지막으로 성공할 때까지 계속해서 잠금을 다시 시도합니다. 따라서 다른 스레드가 대신 사용될 수는 없습니다 (단, 현재 스레드의 CPU 런타임 퀀텀이 초과되면 운영 체제는 다른 스레드로 강제 전환합니다).

문제

뮤텍스의 문제점은 스레드를 휴면 상태로 만들고 다시 깨우는 것이 비용이 많이 드는 작업이므로 상당히 많은 CPU 명령이 필요하므로 시간이 오래 걸리는 것입니다. 이제 뮤텍스가 매우 짧은 시간 동안 만 잠긴 경우 스레드를 휴면 상태로 전환하고 다시 깨우는 데 소요 된 시간이 스레드가 실제로 잠을자는 시간을 초과하고 스레드가 수행하는 시간을 초과 할 수도 있습니다 spinlock에 지속적으로 폴링하여 낭비했습니다. 반면 스핀 락에 대한 폴링은 지속적으로 CPU 시간을 낭비하고 잠금이 더 오랜 시간 동안 유지되면 훨씬 더 많은 CPU 시간이 낭비되며 스레드가 대신 잠 자면 훨씬 좋을 것입니다.

해결책

단일 코어 / 단일 CPU 시스템에서 스핀 록을 사용하면 스핀 락 폴링이 사용 가능한 CPU 코어 만 차단하고 다른 스레드를 실행할 수없고 다른 스레드를 실행할 수 없으므로 잠금이 작동하지 않기 때문에 일반적으로 의미가 없습니다. 잠금 해제되어 있습니다. IOW, 스핀 락은 해당 시스템에서 CPU 시간 만 낭비하여 실질적인 이점은 없습니다. 스레드가 대신 휴면 상태가되면 다른 스레드가 한 번에 실행되어 잠금을 해제 한 후 다시 깨어 난 후 첫 번째 스레드가 처리를 계속할 수 있습니다.

매우 짧은 시간 동안 만 유지되는 잠금이 많은 멀티 코어 / 멀티 CPU 시스템에서 지속적으로 스레드를 휴면 상태로 만들고 다시 깨우는 데 낭비되는 시간은 런타임 성능을 현저하게 떨어 뜨릴 수 있습니다. 대신 스핀 록을 사용하면 스레드가 전체 런타임 양자를 활용할 수 있습니다 (항상 아주 짧은 시간 동안 만 차단 한 다음 즉시 작업을 계속 수행).

연습

뮤텍스 나 스핀 락이 더 나은지 프로그래머가 미리 알 수 없기 때문에 (예 : 대상 아키텍처의 CPU 코어 수를 알 수 없기 때문에) 운영 체제가 특정 코드가 단일 코어 또는 멀티 코어 환경에서 대부분의 시스템은 뮤텍스와 스핀 락을 엄격하게 구분하지 않습니다. 실제로 대부분의 최신 운영 체제에는 하이브리드 뮤텍스와 하이브리드 스핀 록이 있습니다. 이것이 실제로 무엇을 의미합니까?

하이브리드 뮤텍스는 멀티 코어 시스템에서 처음에는 스핀 락처럼 작동합니다. 스레드가 뮤텍스를 잠글 수없는 경우 뮤텍스가 곧 잠금 해제 될 수 있기 때문에 즉시 잠자기 상태가되지 않으므로 대신 뮤텍스가 먼저 스핀 락처럼 작동합니다. 일정 시간 (또는 재시도 또는 기타 측정 요소) 후에도 여전히 잠금을 얻지 못한 경우에만 실이 잠자기 상태가됩니다. 동일한 코드가 하나의 코어 만있는 시스템에서 실행되는 경우 뮤텍스는 위에서 언급 한 것처럼 유익하지 않습니다.

하이브리드 스핀 록은 처음에는 일반 스핀 록처럼 작동하지만 너무 많은 CPU 시간을 낭비하지 않기 위해 백 오프 전략이있을 수 있습니다. 일반적으로 스레드를 잠자기 상태로 만들지 않지만 (스핀 록을 사용할 때 발생하지 않기를 원하기 때문에) 스레드를 즉시 중지하거나 일정 시간이 지나면 다른 스레드가 실행되도록 결정할 수 있습니다 따라서 스핀 록이 잠금 해제 될 가능성이 높아집니다 (순수 스레드 스위치는 스레드를 잠자기 상태로 설정 한 후 나중에 다시 깨우는 방법보다 저렴합니다).

요약

의심스러운 경우 뮤텍스를 사용하는 것이 일반적으로 더 나은 선택이며 가장 현대적인 시스템은 매우 짧은 시간 동안 스핀 록을 허용합니다. 스핀 락을 사용하면 때로는 성능을 향상시킬 수 있지만 특정 조건과 의심 스러울 경우에만 현재 스핀 락이 유리한 프로젝트를 진행하고 있지 않다는 사실을 알 수 있습니다. 스핀 락 또는 뮤텍스를 내부적으로 사용할 수있는 자체 “잠금 개체”를 사용하는 것을 고려할 수 있습니다 (예 : 이러한 동작은 이러한 개체를 만들 때 구성 가능). 처음에 어디서나 뮤텍스를 사용하고 스핀 락을 사용하면 실제로는 도움을 요청하고 결과를 비교하고 (예 : 프로파일 러 사용) 두 경우 모두 테스트해야합니다.

업데이트 : iOS에 대한 경고

실제로 iOS에 국한되지는 않지만 iOS는 대부분의 개발자가이 문제에 직면 할 수있는 플랫폼입니다. 시스템에 스레드 스케줄러가있는 경우 우선 순위가 아무리 낮아도 스레드가 실행될 가능성을 보장하지 않습니다. 스핀 락은 영구 교착 상태로 이어질 수 있습니다. iOS 스케줄러는 서로 다른 클래스의 스레드를 구별하고 하위 클래스의 스레드는 상위 클래스의 스레드도 실행하지 않을 경우에만 실행됩니다. 이에 대한 백 오프 전략이 없으므로, 고급 스레드를 영구적으로 사용할 수있는 경우, 낮은 클래스 스레드는 CPU 시간을 얻지 않으므로 작업을 수행 할 기회가 없습니다.

문제는 다음과 같이 나타납니다. 코드가 낮은 prio 클래스 스레드에서 spinlock을 획득하고 해당 잠금 중간에있는 동안 퀀텀 시간이 초과되어 스레드 실행이 중지됩니다. 이 스핀 록을 다시 해제 할 수있는 유일한 방법은 낮은 prio 클래스 스레드가 다시 CPU 시간을 얻는 경우이지만 이것이 보장되지는 않습니다. 지속적으로 실행하려는 몇 개의 높은 prio 클래스 스레드가있을 수 있으며 작업 스케줄러가 항상 우선 순위를 지정합니다. 그중 하나가 스핀 락을 가로 질러 달려 가려고 시도 할 수 있습니다. 물론 불가능하며 시스템은 그것을 생산할 것입니다. 문제는 다음과 같습니다. 생성 된 스레드를 즉시 다시 실행할 수 있습니다! 잠금을 유지하는 스레드보다 높은 prio를 가지면 잠금을 유지하는 스레드는 CPU 런타임을 얻을 수 없습니다.

뮤텍스에서이 문제가 발생하지 않는 이유는 무엇입니까? 높은 prio 쓰레드가 뮤텍스를 얻을 수 없을 때, 뮤텍스를 얻지 못하고 조금 회전하지만 결국 잠자기 상태가됩니다. 잠자는 스레드는 잠금 해제중인 뮤텍스와 같은 이벤트와 같은 이벤트에 의해 깨어날 때까지 실행할 수 없습니다. Apple은이 문제를 알고 있으므로 OSSpinLock결과적으로 더 이상 사용되지 않습니다 . 새로운 자물쇠를 호출 os_unfair_lock합니다. 이 잠금은 다른 스레드 우선 순위 클래스를 인식하므로 위에서 언급 한 상황을 피합니다. iOS 프로젝트에서 spinlocks를 사용하는 것이 좋다고 확신하는 경우 해당 것을 사용하십시오. 멀리 떨어져OSSpinLock! 그리고 어떤 상황에서도 iOS에서 자신의 스핀 락을 구현하지 마십시오! 의심스러운 경우 뮤텍스를 사용하십시오! macOS는 다른 스레드 스케줄러를 사용하므로 CPU 시간에 스레드 (낮은 prio 스레드)가 “건조”할 수없는 다른 스레드 스케줄러가 있으므로 여전히 동일한 상황이 발생하여 매우 열악하게됩니다. 따라서 성능 OSSpinLock은 macOS에서도 더 이상 사용되지 않습니다.

---

답변