Reactivecocoa: 원자 : SPINLOCK은 iOS에서 안전하지 않습니다.

"불법"이 무슨 뜻인지조차 모르겠습니다.

처음부터 없었기 때문에 궁금합니다.하지만 Atomic 유형이 처음부터 OSSpinLock 사용 된 이유는 무엇입니까?

NSLock 사용한 다음 너무 느린 것으로 나타 났으며, pthread_mutex_t 도 테스트 한 결과 너무 느린 것으로 나타 났습니까? 불행히도 git에는 "소스 이동…"이전에 기록이 없습니다.

Spinlocks는 커널이 아닌 장치 드라이버 컨텍스트에서 사용할 것이라고 생각하는 것이 아니기 때문에 내가 묻는 이유입니다. 어쨌든, 여기서 버그는 OSSpinLock 가 전혀 사용되지 않는다는 것입니다. : stuck_out_tongue :

위의 의견에 대위법을 추가하려면 제목이 다음과 같이 만들 수있는 것만 큼 큰 문제는 아닙니다. https://twitter.com/Catfish_Man/status/676854531615883265

CPU 고갈 상태에서도 중요 섹션이 너무 작아 실제 상황에서 괜찮을 가능성이 높습니다.
— @Catfish_Man 트위터

@kastiglione의 위의 의견은

"불법"이 무슨 뜻인지조차 모르겠습니다.

답은 없지만 ARM CPU의 어떤 것이 스핀 락 프리미티브가 Intel CPU에서와 같은 많은 이점 / 보증 / 가정을 즐길 수 있도록 허용하지 않는다고 생각합니다. (그러나 https://twitter.com/Catfish_Man/status/676851988596809728에 따르면 모두는 아닐 수 있습니다.)

어쨌든, 실제로는 "여기에서 볼 수있는 것이 없음"이있을 가능성이 높으며 대신 @NachoSoto가 제안한 것처럼 더 안전한 기본 형식으로 대체하고 성능 회귀를 측정하기 위해 몇 가지 조사를 수행해야합니다.

https://twitter.com/jspahrsummers/status/679245419931660288 및 후속 조치 ( 참조하십시오.

나는 우리가 OSSpinLock 의 사용을 대체해야한다고 생각하지만, 우리가 사용할 수있는 문서를 고려할 때 그것들을 사용하는 우리 / 내 이유는 타당하다고 생각합니다.

예, 관련 역사 커밋에 감사드립니다. 주어진 파일에 대한 기록이 요청 될 때 GitHub가 git log --follow 수행하지 않는 이유를 모르겠습니다.

어쨌든 나는 "아마 괜찮을 것 같다"는 것을 반복 할 것이다. "이제 더 빨라진"뮤텍스를 사용하는 것은 아마도 간단한 작업 일 수 있지만 시작하기 위해 프로파일 링 / 테스트하는 방법을 모르면 덜 간단합니다. 거기에 제안 / 포인터가 있습니까?

성능이 문제가되는 경우 / 언제 앞으로 나아갈 방법은 잠금없는 대기열을 조사 할 가치가 있습니다. (다음은 개념에 익숙하지 않은 독자를위한 꽤 좋은 기사입니다 : http://www.linuxjournal.com/content/lock-free-multi-producer-multi-consumer-queue-ring-buffer?page=0,0). 얼마 전에 내부 오디오 라이브러리를 위해 비슷한 것을 만들었는데, 이와 같이 일반적인 용도로 적용 할 수있을 것입니다.

"이제 더 빨라진"뮤텍스를 사용하는 것은 아마도 간단한 작업 일 수 있지만 시작하기 위해 프로파일 링 / 테스트하는 방법을 모르면 덜 간단합니다. 거기에 제안 / 포인터가 있습니까?

저는 Instruments의 Time Profiler 및 Allocations에서 GitHub Desktop을 실행하고 있었고 RAC가 많은 스택에 집중했습니다. 지금은 @joshaber 또는 @mdiep 에게

알아두면 좋습니다. Swift 측의 경우 테스트하려면 비슷하게 크고 깊은 코드 기반이 필요하다고 생각합니다. 나는 지난 몇 달 ¹ 이상 내 자신의 일부를 성장하지만 난 그것의 충분한 샘플을 얻기 위해 내가 RAC "열심히"를 밀어 여부를 알 수 없습니다. 다른 많은 것들이 내 앱과 같은 인스트루먼트 차트에 버블 링되는 경향이 있습니다. :미소:

¹ 플러그! http://capoapp.com , http://capoapp.com/neptune 은 가장 최근에 완전히 설계된 RAC4 구성 요소입니다.

저는 오늘 iOS에서 스핀 락이 "불법"인 이유에 대해 자세히 설명하는 블로그 게시물을 작성했습니다. http://engineering.postmates.com/Spinlocks-Considered-Harmful-On-iOS/

나는 조금 전에 Atomic을 중단하고 pthread_mutex_lock으로 마이그레이션했습니다. 모든 계정에서 가장 좋은 잠금 장치입니다. NSLock과 같은 동적 디스패치가 없으며, 스핀 잠금처럼 경쟁하지 않으면 인스턴트 잠금이 스핀 잠금과 달리 에너지를 낭비하지 않습니다.

내 저장소에서 소스를 복사하여 붙여 넣거나 원하는대로 할 수 있습니다.

https://github.com/Adlai-Holler/Atomic
https://github.com/Adlai-Holler/Atomic/blob/master/Atomic/Atomic.swift

@kballard 좋은 설명입니다, 감사합니다!

나는 문제에 대한 전문가가 아니기 때문에 이것에 대해 강한 의견을 가지고 있지 않습니다. 나는 우리가 사용하는 잠금 유형을 변경하거나 변경하지 않기로 결정하는 것을 다른 사람들에게 미룰 것입니다.

이와 같은 벤치 마크는 소스 없이는 완전히 쓸모가 없습니다. 더욱이 시간이 실제로 무엇을 나타내는 지 문서화하지 않고 각 구성에 대해 한 번만 표시합니다. 다양한 구성은 경합 중인지 여부, 잠금에 대해 경합하는 스레드의 우선 순위 등에 따라 다르게 작동합니다. @synchronized 도 흥미로운 짐승이며 성능은 액세스 패턴에 크게 좌우됩니다. , 같은 객체를 반복적으로 잠 그거나 새 객체를 잠그는 지 여부에 관계없이 동시에 들어오고 나가는 @synchronized 블록 수 등

주의 : dispatch_semaphore 는 우선 순위를 기부하지 않으며 이는 또 다른 잠재적 함정입니다.

@jspahrsummers @kballard 원자 CAS를 사용하여 구현했습니다. 관심이 있으시면 PR을 제출해 드리겠습니다.

편집 : Atomic 사용을 보면 내 구현이 유용하지 않을 것이라고 생각합니다. 멱 등성 업데이트를 할 수 있다면 CAS를 사용하면 메모리에서 일종의 낙관적 트랜잭션을 수행 할 수 있습니다.이 트랜잭션은 훌륭 할 수 있지만 상당한 리팩토링이 필요합니다 (모든 것이 CoW 불변이면 정말 잘 작동하지만 돌연변이를 다음과 같이 처리 할 수 ​​있습니다. 메모리 내 트랜잭션).

오늘이 스레드를 발견하고 다양한 유형의 동기화를 조사하고 iOS 시뮬레이터 및 실제 장치에서 벤치 마크를 실행했습니다.
결과는 저에게 매우 흥미 롭습니다. iOS 10에서는 dispatch_semaphore의 성능 저하가 눈에 띄게 나타났습니다. 이는 아마도 스레드 우선 순위를 고려하여 그의 동작을 변경했을 것입니다.
다음은 iOS에서 사용할 수있는 기본 동기화 메커니즘의 요약 다이어그램입니다. 모든 테스트는 릴리스 구성으로 실행됩니다 (Swift 최적화 -O).

SDK9 용 벤치 마크 코드
SDK10 용 벤치 마크 코드

당신의 숫자는 나에게 매우 의심스러워 보입니다. 테스트를 몇 번 실행 했습니까?

비교를 위해 얼마 전에 작성한 해키 벤치 마크 하네스를 사용하여 OS X 10.11.5에서 자체 벤치 마크 ( source )를 실행했습니다. 전체 벤치 마크를 10 번 실행하고 각 테스트에서 상위 2 개 숫자를 삭제하고 (이상 치를 제거하기 위해) 나머지 숫자는 다음 범위를 생성했습니다.

동기화 없음 : 22-41ns
스핀 락 : 24ns
세마포어 : 29ns
NSLock : 45-71ns
뮤텍스 : 40-64ns
동기화 : 75-122ns
대기열 : 505-554ns

여기에서 spinlock이 훨씬 저렴하고 세마포어, 뮤텍스, NSLock이 뮤텍스 (기본적으로 뮤텍스 + objc_msgSend이기 때문에)보다 약간 뒤쳐지고 동기화가 거의 두 배나 비싸고 마지막으로 대기열이 극도로 비싸다는 것을 알 수 있습니다. 내가 예상했던 것보다 훨씬 비싸다.

@kballard 에서 볼 수 있듯이 내 벤치 마크는 매우 간단하지만 실행 시간을 측정하기 위해 기본 xctest 메커니즘을 사용합니다. 숫자는 각 동기화가 아닌 각 테스트의 평균 실행 시간입니다. 일반적으로 당신과 나의 결과는 우리가 생각했던 것처럼 그렇게 나쁘지 않은 대기열을 제외하고는 상관 관계가 있습니다.

원인