Swift Concurrency(with GCD)

안녕하세요. 이번 포스팅은..! 동기, 비동기, 동시, 직렬에 대해 정리해 보고

 

GCD에 대한 간단한 톺아보기와 늘 헷갈리던 Swift Concurrency의 개념과 둘의 차이점에 대해 정리해 보겠습니다.

 

 

이번에 GCD에 대해 공부해 보다, WWDC 2021에 나온 swift concurrency가 GCD가 있는데 왜 나왔을까 하는 생각이 들었습니다.

 

우선 GCD에 대해 간단히 정리해 보면,

 

#GCD

기존의 Swift는 동시성 프로그래밍을 구현하기 위해서 GCD를 사용해 왔습니다. 비동기의 코드 블록을 DispatchQueue라는 매니저(Queue)에 넣어서 블록을 스레드에 작업을 할당하는 방식입니다. GCD는 주로 @escaping 클로저를 활용해 작업 객체에 대한 콜백을 받습니다.

 

그렇다면 잘 사용하고 있던 GCD가 있는데, Swift Concurrency가 나온 이유는 무엇일까요?

 

#Swift Concurrency란?

Swift Concurrency는 2021 WWDC에서 발표된 최신 동시성 프로그래밍입니다. 아래의 영상에서 애플에서 말하길 조금 더 나은 비동기 프로그래밍 환경을 위해 나오게 되었다고 소개하고 있습니다. 

 

https://www.youtube.com/watch?v=r_clm92NI1s

 

함수에 async로 비동기 코드임을 나타내고, await로 해당 비동기의 코드 블록이 완료될 때까지 기다린다는 전체적인 의미를 가지고 있습니다.  await 키워드로 인해 중지되면 이후에 사용해야 하는 데이터를 힙 영역에 저장해 두고, 이후에 다시 힙 영역에서 해당 데이터를 가져와 사용합니다.

 

그렇다면, 애플에서 말하는 Swift Concurrency의 장점(GCD와의 차이점)은 무엇일까요? 

 

1. 가독성 향상

첫 번째, 특징으로는 가독성 향상이 있습니다. 애플에서 제공해 준 코드 블록을 살펴보겠습니다.

 

우선 두 코드블록의 차이가 한눈에 보기에도 보이시듯, 가독성의 차이가 많이 납니다. @escaping 클로저를 사용했던 위의 코드에서는 에러처리를 분기마다 사용하고 있습니다. 하지만, swift concurrency를 사용한 코드에서는 클로저 구문이 사라지고, 에러처리의 과정도 간소화되었습니다. 

 

또한, GCD는 에러처리를 많이 해주다 보니 개발자가 만약 에러 처리를 하지 않는 실수가 발생해도 컴파일러에서는 이를 오류라고 판단하지는 않았습니다.

 

하지만 swift Concurrency는 try - throw 키워드로 에러 핸들링을 통해 개발자가 실수를 하더라도 컴파일러에서 오류를 판단할 수 있기에 개발자가 즉각적으로 대응이 가능합니다.

 

2. 경쟁 상태(Race Condition)

두 번째, Swift Concurrency의 장점이며 두 과정의 차이점인 경쟁상태의 핸들링입니다. 우선, GCD의 경우에는 비동기로 돌아가는 과정에서 여러 스레드가 하나의 공유자원에 접근하게 되는 일이 생길 수도 있습니다. GCD는 이를 방지하기 위해서 NSLock, 뮤텍스, 세마포어, 직렬 큐 등으로 이 과정을 처리해 줘야 합니다.

 

비동기적으로 코드를 작성하게 된다면, 여러 개의 스레드가 생성되게 됩니다. 덕분에 여러 작업을 동시에 실행할 수 있게 되기도 합니다. 사실  동시에 실행되는 것처럼 보이지만, 컴퓨터의 입장에서 보면 동시에 실행되는게 아닙니다.

 

CPU, 코어는 하나의 작업만을 할 수 있습니다, 결국 코어는 여러개의 스레드로 동시에 실행되는 것이 아닌 여러개의 스레드에 할당된 과업을 빠르게 이동하면서 작업을 처리하는 것입니다. 이 과정을 *컨텍스트 스위칭(context switching)이라고 합니다. 결국 스레드가 많다는 것은 이 과정이 많이 일어남을 뜻합니다.

 

스레드는 여러 영역 중 Stack이라는 메모리 영역을 할당받게 됩니다. 결국 스레드가 많아지게 된다면, 메모리 관점에서도 좋지 않은 결과를 불러낼 수 있습니다. (*메모리 오버헤드)

 

또한 이 과정을 처리하기 위해 코어에서는 많은 컨텍스트 스위칭이 발생하게 될 것이며, 사실상 빠르게 스위칭이 일어나지만 이 과정에서 약간의 공백이 발생하게 되는 *스케줄링 오버헤드가 발생하게 됩니다.

 

결론적으로, 비동기 프로그래밍이 중요하지만 스레드의 개수가 적을수록 성능적으로 유리하다고 볼 수 있습니다. GCD의 경우에는 DispatchWorkItem마다 스레드를 생성하여 해당 스레드에서 작업을 처리합니다. 

 

하지만 Swift Concurrency는 *thread explosion(스레드의 수가 지나치게 많이 생성되는 현상)을 방지해 주는 기능을 내포하고 있습니다. 

 

1. CPU 코어 수 이상으로 스레드를 생성하지 않는다.

2. 스레드 간 스위칭이 아닌 continuation을 둬 이 continuation 간 스위칭을 하여 작업을 처리한다.

3. await 키워드가 읽힌 스레드는 멈추는 것이 아닌 다른 async 작업이 할당된다.

 

CPU가 컨텍스트 스위칭을 해서 다른 스레드를 불러오는 것이 아니라 같은 스레드에서 다음 함수를 실행시킵니다. 결국 코어의 갯수와 스레드의 갯수가 동일하다라는 뜻이며, 코어가 하나의 스레드를 실행하도록 유지하는 것을 보장합니다. 기존 스레드의 컨텍스트 스위칭으로 진행되던 것들이 같은 스레드 내의 함수 호출로 대체되는 것입니다.

 

*continuation이란?

async 한 메서드를 호출할 때 스레드의 제어권을 포기하는 suspended라는 현상이 발생하게 됩니다. 다시 제어권을 돌려받았을 때, 어디서부터 실행해야 할지 알아야 하는데! 비동기 함수의 경우 heap suspension point에서 실행하는데 필요한 함수 컨텍스트들을 저장해서 제어권을 돌려받았을 때 어디서 실행해야 할지 알 수 있게 됩니다. 이 과정을 continuation이라고 부릅니다!

 

heap에서 저장하는 이유는 변수가 await의 suspension point이전에 정의되어 있는데 await 이후에 사용하려는 경우에 해당 변수가 사라지면 안 되고 저장되어야 하기 때문입니다. stack에 저장하게 된다면 다른 await 메서드에 의해 replace 되는 경우에 변수 자체가 사라지기 때문에 heap(async frame)에 저장이 됩니다.

 

GCD에서는 스레드가 block이 되면 task 자체를 다른 스레드로 보내는 "full thread context switching"이라는 큰 비용이 발생하게 되는데, continuation을 사용하면 "function call" 정도의 비용으로 비동기 메서드를 호출하고 사용할 수 있습니다.

 

 

3. 우선순위 관리

우선 GCD의 경우에는 QOS(Quality Of Service)를 이용하여 우선순위의 추세를 관리하고 있습니다. 비동기 작업을 하고 있을 때 진행하고 있는 작업보다 높은 우선순위의 작업이 들어오게 된다면, 높은 우선순위의 작업부터 완료하게 됩니다. 모든 작업이 우선순위에 있는 것은 아니고! 대부분의 추세가 그러합니다!

 

GCD의 경우에는 매니저인 Queue에서 작업을 할당해 주기 때문에 우선순위에 대한 성능은 떨어진다고 볼 수 있습니다. 반면, Concurrency의 경우에는 Queue를 사용하지 않기 때문에 우선순위에 대한 작업을 더 우수하게 실행할 수 있습니다.

 

 

이번 시간에는 Swift Concurrency에 대해 GCD와 함께 공부하며 정리해 보았습니다! 공부를 하다 보니 정말 끝도 없는 주제라고 생각하였고, 새로운 지식을 알게 되면 바로바로 업데이트하겠습니다 ㅎㅎ!

 

긴 글 읽어주셔서 감사합니다.

 

 

참고, 

 

https://engineering.linecorp.com/ko/blog/about-swift-concurrency

Swift Concurrency에 대해서