Thread 는 어렵고, 위험하고 … 효과를 내기도 힘들고.. 다른 방법 제공.
Mac과 iOS에 모두 적용됨.
Concurrency and Application Design
코어의 증가.. 어떻게 사용할 것인가.. 동시에 여러 일 수행.
시스템 데몬, 백그라운드 프로그램.. 하지만, 프로그램 자체가 이용해야 함.
고전적 방법은 여러개의 쓰레드..
하지만, 쓰레드는 임의의 코어수에 스케일이 잘 안 맞음.
쉽고, 여러 코어에 대응할 수 있는 방법을 제공한다.
The Move Away from Threads
쓰레드에 대한 책임은 솔직히 (squarely) 개발자의 어깨에 놓여져 왔다. 맥에서는 쓰레드에 의존하는 대신 비동기 디자인 접근방식을 취한다.
데이터를 읽는 등의 ‘큰 작업’에 종종 이용되어 왔다. 전형적으로 이 작업은 백그라운드 쓰레드를 채용하며 원하는 작업을 그 쓰레드에서 시작하고 일이 끝나면 콜백함수를 통하여 콜러에게 노티를 보낸다.
비동기 작업의 하나는 GCD : Grand Central Dispatch 이다. 당신이 쓰는 쓰레드 관리 코드를 시스템 레벨로 옮긴다. 당신이 해야할 것은 태스크를 정의하고 그것을 적절한 디스패치 큐에 추가하는 것이다. GCD가 필요한 쓰레드를 생성하고 스케쥴링한다. 쓰레드 관리가 시스템의 일부이므로 GCD 가 더 좋은 효율을 제공한다.
Operation queues 는 Objective-C 객체. 디스패치 큐와 비슷함. 일을 정의하고 오퍼레이션 큐에 붙이면 스케쥴링과 수행을 한다. GCD와 같이 오퍼레이션 큐는 쓰레드 관리를 하며 가장 효율적으로 일을 처리한다.
Dispatch Queues
디스패치큐는 씨-기반 메커니즘. FIFO로 처리.
시리얼 디스패치 큐 ; 한번에 한 작업 처리. 작업이 끝나 디큐잉할 때까지 기다렸다 새로운 작업 시작. 대조적으로, 컨커런트 디스패치 큐는 최대한 많은 태스크를 동시에 시작.
디스.. 큐의 장점
– 직접적이고 간단한 프로그래밍 인터페이스
– 자동 / 전체적인 쓰레드 풀 관리
– 튠드 어셈블리의 속도 제공
– 메모리 효율적
– 커널을 잡지 않음.
– 디스..큐에 추가하는 비동기 처리는 큐를 데드락 하지 않음.
– 스케일 우아함.
– 시리얼 디스. 큐는 락과 다른 동기화 원소보다 효율적
작업은 ‘함수’ 나 ‘블락’으로 캡슐화 되야 함. 블락은 …. 블락은 오리지널 스코프에서 옮겨져 힙에 카피될 수 있다. 이것이 디스..큐에 넘길 때 일어나는 일.
이러한 것들을 통해 적은 코딩으로 동적인 태스크를 구현할 수 있음.
디스패치 큐는 GCD 기술의 일부이며 C 런타임의 일부이다.
Dispatch Sources
디스.소스는 씨-기반 메커니즘. 특별한 타입의 시스템 이번트를 비동기로 프로세싱함.
시스템 이벤트의 특정 타입에 대한 정보를 캡슐화하여 그 이벤트가 발생할 때마다 특정 블락/함수를 디스..큐에 서밋한다.
다음 이벤트를 모니터할 때 사용.
– 타이머
– 시그널 핸들러
– Descriptor-related events
– Process-related events
– Mach port events
– Custom events that you trigger
디스.소스는 GCD기술의 일부임.
Operation Queues
Concurrent dispatch queue에 대한 코코아 버전. NSOperationQueue 클래스에 구현.
디스. 큐가 FIFO임으로 오퍼.큐는 실행 순서를 정할 때 다른 사항 고려. 가장 우선은 다른 작업의 완료에 디펜드 하냐. 당신이 디펜던시 지정할 수 있고, 이용할 수 있음. 복잡한 실행순서 그래프를 만들어서..
오퍼.큐에 넘기는 작업은 NSOperation의 객체여야 함. 작업과 데이터를 캡슐화한 것임. NSOperation 은 추상클래스이므로 상속받아 수행한다. 하지만 코코아 프레임워크는 든든한 섭클래스 제공.
KVO 노티 생성.. 작업 프로세스를 모니터 하기 유용함.
Asynchronous Design Techniques
동시성을 고려할 때 꼭 필요한지 숙고해야. 동시성은 코드의 반응성을 개선 .. 메인 쓰레드가 당신의 이벤트에 반응하는 데서 자유로운것에 의해. 같은 시간에 여러 코어를 이용해서 효율을 높이기 때문에.. 하지만, 오버헤드를 추가하고, 코드에 복잡성을 높인다. 코딩, 디버깅이 힘들어짐.
이 복잡성 때문에 프로젝트 마지막에 할 일은 아니다. 미리 고려해야.. 데이터 타입 등등.. 잘못 짜면 더 나빠진다. 미리 고려해라..
다음 글이 도움이 될 것.
Define Your Application’s Expected Behavior
당신 앱의 적절한 행동을 정의. 먼저 작업의 수를 결정?? 객체, 데이터 구조.. 메뉴를 고르고 버튼을 클릭하고… 이런 명확한 작업들.. UI없이 해야할 일. 타이머 관련 작업들..
디펜던시..
Factor Out Executable Units of Work
어플의 작업을 이해하면 동시성의 이득을 발견할 수 있다. 작업 순서를 바꾸면 결과도 바뀐다. 순서를 바꿔도 결과가 같으면 동시에 수행할 것을 고려해야 함.
작업의 양은 처음에는 너무 신경쓰지 마라. 쓰레드를 돌리는 데는 비용이 들지만 디스.큐, 오퍼.큐 등은 기존 쓰레드보다 덜 든다.
Identify the Queues You Need
작업이 구분되서 캡슐화 되었으면, 큐를 정의해야한다. 블락을 이용했으면 시리얼/콘코런트 디스. 큐에 추가할 수 있다. 순서가 필요하면 시리얼 디스. 큐에 항상 추가해라. 순서가 필요 없으면 컨커런트에 추가하던지 여러개의 다른 디스. 큐에 추가할 수 있다.
오퍼레이션 객체에 정의했으면 큐의 선택은 덜 중요할 수 있다. 오퍼. 객체를 연속적으로 수행하려면 디펜던시를 규정해야 한다. 디펜던시는 전처리 작업이 끝나기 전까지 작업 시작을 막는다.
Tips for Improving Efficiency
– 메모리 사용이 중요하면 컴퓨팅 값을 직접 고려해라.
– 여러 태스크를 미리 확정하고 더욱 동시화 위해 할 것을 해라.
– 락 사용 자제. 큐 이용시 락은 대부분의 경우 불필요. 공유하는 리소스를 보호하기 위해 락을 사용하는 대신, 시리얼 큐 (또는 오퍼. 객체 디펜던시) 를 사용할 것.
– 가능하면 시스템 프레임웤에 의존할 것.
Performance Implications
이런 기술들은 효율을 보장하진 않음.
Concurrency and Other Technologies
OpenCL and Concurrency
맥에서 이놈은 표준 그래픽 프로세서임… 이미지의 필터 계산 등.. 복잡한 수학 계산 등. 대규모 병렬 계산.
일반 목적 계산에는 안 어울림.
When to Use Threads
큐 들.. 만병통치약은 아님.. panacea.
리얼 타임을 원하면 해라..
MPS 