[Swift] GCD(Grand Central Dispatch) - Dispatch Queue

GCD(Grand Central Dispatch)랑 Dispatch Queue랑 같은거야?

이 포스트를 준비하면서 "우리는 왜 Dispatch Queue를 GCD라고 할까?"라는 의문이 먼저 들었습니다. 그래서 공식문서를 찾아보니 GCD와 Dispatch Queue는 내용이 다르더라구요. 먼저 이 부분부터 정리하고 Dispatch Queue에 대해 정리해보겠습니다.

💡Dispatch, also known as Grand Central Dispatch (GCD), contains language features, runtime libraries, and system enhancements that provide systemic, comprehensive improvements to the support for concurrent code execution on multicore hardware in macOS, iOS, watchOS, and tvOS.

공식문서는 GCD를 위처럼 설명하고 있습니다. GCD는 멀티코어 시스템에서 동시성 실행을 제공하는 프로그래밍 언어 요소, 런타임 라이브러리 등이라고 합니다. 그래서 엄밀하게 말하면 GCD 와 Dispatch Queue는 동치가 아니고, GCD의 개념으로 동시성 프로그래밍을 지원하는 스위프트의 API가 Dispatch Queue인 것이죠!

 

 그럼 이제 본격적으로 Dispatch Queue를 공부해볼까요?

동시성 실행? 그거 내가 해준다..!

자바나 C같은 언어를 생각해보면, 스레드를 생성하기 위해서 명시적으로 스레드를 만들고 해야할 작업도 특정한 스레드에 지정해주어야 했습니다.

이렇게 개발자의 책임이 많아지는 구조였죠. 그래서 멀티스레딩 환경을 만드는 것은 복잡하고 어려운 일이었습니다. 리소스 관리도 직접 해주어야했구요.

하지만 Dispatch Queue를 사용하면, 개발자가 할 일은 하나로 줄어듭니다. 작업을 정의해서 Dispatch Queue에 넣어주는 일이죠. 운영체제는 Dispatch  Queue에 있는 작업들을 적절한 스레드에 할당하게 됩니다. 이 때문에 개발자는 자신이 등록한 작업이 어떤 스레드에서 실행될지 알 수 없죠.

 

사실 개발자가 지정해줄 수 있는 옵션들이 몇가지 더 있습니다. 어떤걸 설정해줄 수 있는지 알아보기 위해서 먼저 기본적인 Dispatch Queue의 사용법에 대해 알아봅시다!

 

Dispatch Queue 사용하기

DispatchQueue는 기본적으로 위처럼 사용할 수 있습니다. 개발자는 큐의 종류, qos 우선순위, sync, async를 설정해서 지정한 작업을 DispatchQueue를 통해 현재 스레드, 혹은 다른 스레드에서 실행되도록 할 수 있습니다.

 

Serial vs. Concurrent

여러가지 옵션들을 알아보기전에, Dispatch Queue가 가질 수 있는 두 특성에 대해 먼저 정리해보곘습니다.

 

먼저 Serial은 큐에 등록된 작업을 한 번에 하나씩 처리하는 것을 의미합니다.

이 코드를 실행하게 되면 결과는 항상 0, 1, 2, 3, 4 순서가 보장되는데요, 그 이유가 Serial 큐로 만들어진 Dispatch Queue이기 때문에 먼저 들어온 작업이 완료되어야 큐에 있는 다음 작업을 시작하기 때문입니다.

이렇게 한 작업이 끝날 때까지 큐에 있는 다른 작업은 건드리지 않기 때문에 실행의 순서가 언제나 같습니다.

 

반면에 concurrent 큐는 이름이 나타내는 것 처럼 동시에 여러작업이 수행될 수 있게합니다. 운영체제는 Dispatch Queue에서 꺼내온 현재 작업이 끝나지 않아도 다음작업을 다른 스레드에 할당해서 동시에 여러 작업이 실행되도록합니다.

그래서 이렇게 Dispatch Queue를 concurrent로 만들어서 실행하면,

이렇게 매번 다른 결과가 나오게 됩니다. 각 스레드에서 작업이 끝나는대로 출력을 수행하기 때문입니다. 이번에도 그림으로 살펴보죠!

실제로는 당연히 더 많은 스레드가 있어서 모든 작업을 한 번에 처리하겠지만 개념적으로는 이렇게 한 작업이 끝나지 않아도 동시에 여러 작업을 스레드에 할당합니다.

Main Queue, Global Queue, Custom Queue

Dispatch Queue를 사용할 때 우리는 세 종류의 큐를 선택하여 사용할 수 있습니다. 

Main Queue

Main Queue는 이름 그대로 메인 스레드에서 작업을 보관하고 수행하는 큐입니다. Main Queue는 메인 스레드에서 동작하기 때문에 단 하나만 존재할 수 있고, Serial 특성을 가지고 있죠. 즉, 큐에 쌓이는 작업을 순차적으로 실행합니다. 메인 스레드는 앱과 함께 생성되면서 아주 중요한 임무를 부여받는데요, 바로 UI의 업데이트 입니다. 

 

화면 위에 보여지는 앱 요소들은 모두 메인 스레드에서 그리고 있습니다. 따라서 UI업데이트와 관련된 모든 작업은 다른 큐가 아닌 Main Queue에 할당되어야 합니다.

위에서 사용했던 예제를 Main Queue를 사용하는 코드로 변경해보면 이렇게 쓸 수 있습니다. 제일 처음에 보았던 뼈대 코드에서 큐 종류를 설정하는 부분에 main을 넣어주면됩니다. 이 코드를 실행해보면, Main Queue는 Serial하기 때문에 언제나 0, 1, 2, 3, 4를 순서대로 출력합니다.

Global Queue

Global Queue는 메인 스레드가 아닌 다른 스레드에서 작업을 처리합니다. 그리고 동시에 concurrent 특성을 가지기 때문에 여러 스레드로 작업이 분산되어 동시에 처리됩니다.

Global Queue는 코드로 이렇게 작성할 수 있고, 이 코드의 결과는 concurrent 특성에 따라 항상 같은 순서의 출력을 보장하지는 않습니다.

Custom Queue

Custom Queue는 사용자가 어떤 특성의 큐로 Dispatch Queue를 생성할지 결정할 수 있도록 해줍니다. 기본값으로는 Serial을 가지고있지만, 생성시에 attributes 인자를 통해 concurrent로 변경하는 것이 가능하죠.

이렇게 DispatchQueue를 생성하면서 라벨을 주면 기본값인 Serial 특성을 가지는 큐가 생성되고,

인자를 하나 추가하면 concurrent로도 만들 수 있습니다.

 

Quality of Service - QOS

사실 Custom Dispatch Queue와 Global Dispatch Queue에는 적용할 수 있는 옵션이 하나 더 있는데요, 바로 qos 로 불리는 quality of service 입니다. Concurrent 하게 작업이 분산되어 실행될 때, 어떤 작업의 중요도를 설정해서 실행의 우선순위를 부여할 수 있습니다. 우선순위가 더 높은 큐는 더 많은 스레드에 작업은 분산시키고, 우선순위가 낮은 큐는 상대적으로 적은 스레드에 작업을 분산시킵니다.

 

qos의 종류는 총 5가지가 있어요!

1. userInteractive: 가장 높음! 사용자와 직접 상호작용을 하는 작업을 의미하기 때문에 사용자의 요청에 곧바로 응답이 있어야합니다. 애니메이션 처리, 이벤트 처리, UI 업데이트 등의 경우입니다. 그래서 가장 높은 우선순위를 가지죠.
2. userInitiated: 사용자가 어떤 요청을 했을 때 그 결과를 곧바로 받아야하거나 사용자가 앱을 사용하는 것을 순간적으로 막기 위한 경우입니다. 예를 들면 사용자에게 보여줄 이메일 내용을 로드할 때, 이 qos를 사용할 수 있습니다.
3. default: 기본값으로 일반적인 작업의 경우입니다.
4. utility: 사용자가 앱을 계속 사용하지 않도록 막지 않는 작업에 사용할 수 있습니다. 예를 들면 이 qos는 사용자와 상호작용하지 않으면서 오랜시간동안 어떤 작업을 진행해야할 때 사용할 수 있습니다.
5. background: 가장 낮은 우선순위를 가지는 qos이고, 앱이 백그라운드에서 실행중일 때 진행하는 작업에 이 qos를 사용할 수 있습니다.

Sync vs. Async

마지막으로 Sync 와 Async를 지정할 수 있습니다! Sync는 큐에 작업을 등록한 이후에 해당 작업이 완료될 때까지 더 이상 코드를 진행하지 않고 기다리는 것을 의미하고, Async는 큐에 작업을 등록하면 작업의 완료여부와 상관없이 계속 코드를 실행시키는 것을 의미합니다.

 

serial, concurrent에서 동시성에 대해 다루었는데, 갑자기 동기, 비동기가 나오니까 헷갈리시죠? Sync, Async는 Dispatch Queue에 작업을 등록하는 주체에 대한 설정입니다. concurrent, serial은 이미 큐에 들어온 작업을 어떻게 처리하냐에 대한 설정이었죠. 그래서 sync / async, serial / concurrent를 모두 조합할 수 있습니다.

 

하나씩 직접 해봅시다!

Sync + Serial

먼저 Sync와 Serial을 함께 사용하는 경우입니다. Sync로 설정했으니 코드가 실행될 때 Serial Dispatch Queue에 작업을 하나 등록하면, 해당 작업이 끝날 때까지 기다리겠죠? 그리고 Dispatch Queue 쪽에서는 메인 스레드로 해당 작업을 보내 처리하도록 할 것입니다.

 

코드로는 

이렇게 표현할 수 있고, 그림으로 나타내보면

이렇게 진행이 되겠죠? 결국 큐에는 한 번에 하나의 작업만 들어가고, 이 작업은 항상 메인스레드에서 실행됩니다.

메인 스레드에서 main.sync 멈춰!

위 예시에서는 Custom Queue를 직접 만들어서 사용했는데요, Serial 특성을 가지는 Main Dispatch Queue를 사용하면 어떻게 될까요?

이렇게 에러가 나고맙니다. 그 이유는 Serial Queue와 메인스레드에 있는데요, Main DispatchQueue에서 sync를 호출하면 메인 스레드는 그대로 진행을 멈추고 등록한 작업이 끝날때까지 기다리게 됩니다. 그리고 동시에 큐에 등록된 작업은 메인스레드로 할당되죠. 하지만 메인 스레드는 이미 아무것도 할 수 없는 상태이기 때문에 작업을 수행할 수 없습니다. 이 때문에 큐에 등록된 작업은 시작이 되지 못하고 영원히 실행되지도, 작업이 끝나지도 않는 데드락 상태에 빠지게 됩니다. 

같은 큐에서 sync 멈춰!

한 가지 조심해야할 부분이 또 있습니다. 같은 큐에서 같은 큐로 sync를 보내는 상황입니다.

main.sync를 피해야하는 이유를 이해했다면, 이 코드에서 발생하는 문제도 이해하기 편할텐데요, 같은 큐에서 작업을 등록하고, 해당 작업을 동일 큐에 sync로 등록하게 되면 항상 그렇지는 않지만 잘못하면 같은 스레드에 다시한번 작업을 할당하게 될 수도 있습니다.

 

외부 Dispatch Queue가 스레드1에 내부 Dispatch Queue를 실행하는 작업을 등록했을 때, 해당 스레드1에서 sync로 print(numbers[index])를 큐에 등록하고, 운영체제가 등록된 출력작업을 다시 스레드1에 할당하면 sync된 스레드1은 아무작업도 하지 못하는 데드락이 발생하게됩니다.

Serial + Async

serial + async는 작업의 등록은 작업 완료여부와 상관없이 계속 진행하고, 작업의 수행은 순차적으로 진행합니다. 따라서 코드는 아래처럼 작성할 수 있고,

 

그림으로 정리해보면

이렇게 모든 작업들이 작업의 결과와 상관없이 큐에 등록되고, 작업은 큐에서 하나씩 꺼내서 메인스레드에서 처리하게 됩니다. 따라서 이 경우에는 작업들의 등록순서와 출력순서가 일치합니다.

Concurrent + Sync

Concurrent+Sync에서는 작업이 끝날 때까지 대기하면서, 큐에 등록되는 작업들은 여러 스레드에 분산되어 처리됩니다.

이렇게 실행되면 concurrent 특성을 가진 queue이지만, 작업을 sync로 등록하기 때문에 작업의 등록 순서와 출력 순서가 항상 일치하게 됩니다.

Concurrent + Async

마지막으로 Concurrent + Async는 작업을 완료 여부와 상관없이 계속 등록하고, 등록된 작업들은 스레드에 분산되어서 동시에 실행됩니다. 따라서 등록순서와 출력순서가 항상 일치하지는 않습니다.

이번 포스트에서는 GCD의 Dispatch Queue에 대해서 정리해보았습니다! main.sync의 이유나 qos에 대해 더 확실하게 정리할 수 있어서 의미가 있었던 것 같아요! 잘못된 내용이나 자료가 있다면 알려주세요! 오늘도 읽어주셔서 감사합니다 :)