Concurrency

WWDC21의 주요 주제는 Concurrency라고 생각합니다.

21년에 처음 공개된 후 관련된 포스트도 많아졌고 서드파티 라이브러리에서도 대응 업데이트가 많이 이루어진 상황입니다.

이제 슬슬 실무에 사용되는 모습들도 보이기 시작하는 것 같습니다.

어렴풋이 “async와 await를 사용하는 문법이다.” 정도로만 알아두고 나중에 공부해야겠다 생각했지만 프로젝트에서 callback 지옥을 본 순간.. 학구열이 올라 한 번 학습해봤습니다.

WWDC21의 세션들을 살펴보았더니 관련 세션만 거의 10개에 달하고 하나하나의 내용들도 꽉 찬 20~30분 정도를 이루고 있더군요..

그래서 내용이 무지무지 많습니다.. 🫠

비동기 프로그래밍

비동기 코드는 “나중에 언젠가 호출되어 실행될 코드” 입니다.

그 시기는 보장되지 않으며 순서 또한 보장되지 않을 때도 있습니다.

Swift에서는 우리가 흔히 GCD라고 부르는 DispatchQueue를 통해 지원하는 개념이였죠.

print("1")
DispatchQueue.main.async {
  print("2")
}
print("3")

위 코드의 print("2") 구문은 비동기 코드입니다.

따라서 순서와 호출 시기가 불확실합니다.

바로 호출될수도 있고 아닐수도 있죠.

1 2 3

1 3 2

그래서 위와 같이 실행마다 결과가 다를수도 있습니다.

비동기코드는 1. 해당 라인에 도달되도 바로 실행되지 않고, 2. 이후에 있는 코드의 실행을 Blocking하지도 않습니다.

비동기 코드가 언제 실행되는지 모른다면, 비동기적으로 산출된 어떤 값을 언제 사용해야 할까요?

다행히도 비동기 코드가 종료되는 시점은 우리가 알 수 있습니다.

@escaping 클로저를 통해서요.

func foo() {
  print("1")
  asyncFoo(completion: { value in
    print(value)
  })
  print("3")
}

func asyncFoo(completion: @escaping (String) -> Void) {
  DispatchQueue.main.async {
    let a = "2"
    completion(a)
  }
}

asyncFoo 메서드에서 completion 클로저는 async 함수가 종료되는 시점에 호출되어 콜러인 foo 메서드에 String 타입 파라미터 value를 제공합니다.

이런 방식의 문법은 어떤 함수가 끝났을 때의 동작들의 묶음을 명시적으로 모아둘 수 있다는 장점이 있지만 (장점인가..?) callback 지옥과 코드 가독성이 떨어진다는 문제점을 가집니다.

GCD의 진짜 문제점

코드의 가독성과 개발자에게 주는 불쾌한 경험도 중요하지만 GCD에는 더욱 크리티컬한 단점이 존재합니다.

바로 CPU의 불필요한 추가 동작과 과도한 리소스의 사용을 유발할 수 있다는 점입니다.

이게 무슨 말인지 살펴볼까요?

DispatchQueue에 동작이 enqueue되면, 시스템은 해당 작업이 수행될 쓰레드를 불러오고 수행시킵니다.

만약 무수히 많은 동작들이 enqueue되면, 시스템은 해당 동작들을 동시에 수행하기 위해 쓰레드를 계속해서 불러옵니다. CPU의 코어가 더 이상의 쓰레드 작업을 추가할 수 없을 때까지요.

코어가 2개인 환경에서 쓰레드를 추가적으로 불러오는 상황

하나의 코어가 여러개의 쓰레드를 가지고 있는 이유는 여러가지입니다.

1. 하나의 쓰레드가 Block되더라도 코어가 쉬지않고 다른 쓰레드의 작업을 할 수 있도록 하기 위해
2. 쓰레드간의 Race Condition을 해결하기 위해 (Semaphore 참고)

그런데 과연 Blocking된 쓰레드가 많아진다고 쓰레드를 무수히 많이 불러오는 것이 항상 좋을까요?

당연히 아니겠죠..

쓰레드들이 Blocking된 상태에서 추가적으로 쓰레드를 계속 불러온다면, 더 이상 코어가 쓰레드를 불러올 수 없는 상태가 됩니다.

해당 현상을 Thread Explosion이라고 부릅니다.

Swift는 이를 해결하기 위해 DispatchSemaphore와 같은 기능을 제공하고 있기는 합니다. 문제는 사용하기에 너무 번거롭다는 것이죠..!

Thread Explosion 현상이 발생하면 OS는 여러 문제를 마주칩니다.

• 메모리 오버헤드

Block된 쓰레드는 각자 메모리와 리소스를 점거하고 있습니다. 다른 쓰레드의 unlock을 위해 필요한 리소스를 점거하고 있을 수도 있죠.

• 스케줄링 오버헤드

CPU의 코어는 쓰레드간의 전환을 위해 컨텍스트 스위칭(Context Switching) 이라는 작업을 수행해야 합니다. 쓰레드가 폭발적으로 많아지면 컨텍스트 스위칭도 빈번히 일어나 불필요한 작업이 늘어납니다.

자 그래서 Swift는 이런 현상을 어떻게 해결했느냐?

async / await

새로운 Swift의 asynchronous 개념 async / await와 concurrency를 통해서죠.

실은 멀티 쓰레딩의 이러한 오버헤드들은 이전부터 다양한 언어와 운영체제 전문가들에게 문제시 되어왔습니다.

이들이 제시한 방법은 바로 Coroutine 방식이였습니다.

오래전 멀티쓰레딩 방식이 제시되고 통용되기 시작하며 자연스럽게 버려졌던 Coroutine 방식이 현대에 와서 다시 연구되고 발전하고 있죠.

실제로 Python, Kotlin과 같은 언어들이 적극적으로 Coroutine 방식을 사용하고 있습니다.

그래서 Coroutine 방식은 어떤 방식이냐?

코루틴(Coroutine) 은 CPU의 코어 개수만큼만 쓰레드를 만들고 쓰레드를 차단하는 대신 작업을 막아둠으로써 컨텍스트 스위칭을 차단합니다.

Swift 용어로 바꾸어볼까요?

Swift Concurrency는 쓰레드의 차단(Blocking)을 없애고 작업의 재실행(Resumption of Work)를 추적하는 continuation이라는 객체를 통해 Context Switching 대신 같은 쓰레드 내에서 Continuation Switching을 수행하여 동시성 프로그래밍을 지원합니다.

자 Concurrency가 (모순적이게도) 현대적이고 좋다는 건 알았어요.

그래서 async / await은 어떻게 사용할까요? 😒

WWDC에서도 사용한 기존의 @escaping 클로저를 사용하는 예시를 가져와봤어요.

시스템적인 단점 말고 코드 작성의 측면에서 @escaping 클로저 방식은 세가지 단점을 가지고 있습니다.

1. completion 클로저 호출을 까먹기 쉽습니다. (여러군데에 필요)
2. callback이 중첩해서 발생하는 경우가 많습니다.
3. 코드 가독성이 떨어집니다.

자 그런데 async / await를 사용한 코드로 바꿔보면요?

엄청 짧아지고 수많았던 중괄호들이 사라졌어요! 👏

async

함수의 파라미터와 반환타입 중간에 async 를 붙여줌으로써 해당 함수가 비동기적이다 라는 것을 나타내줍니다!

throws를 통해 해당 함수가 에러를 방출할 수 있다라는 것도 함께 명시해줄 수 있습니다.

await

async로 정의된 함수를 호출하기 위해서는 Concurrent Context 내부에서 await 키워드를 붙여주어야 합니다.

let (data, response) = try await URLSession.shared.data(for: request)

주의할 점은 정의할때는 순서가 async throws지만, 사용할때는 try await 순서라는 것을 알아두어야합니다.

await 키워드는 해당 라인이 Suspension Point라는 것을 명시하는 역할을 합니다.

Suspend

await 포인트를 만나면 된다는 Suspend는 또 뭘까요?

Suspend는 “해당 스레드가 다른 동작을 수행할 수 있도록 스레드의 통제권을 시스템에게 넘겨준다” 라는 것을 의미합니다.

일반적인 synchronous한 코드의 경우에는 위와 같이 동작합니다.

fetchThumbnail 함수에서 thumbnailURLRequest 함수를 호출하고 있습니다.

이 때 두 함수 모두 sync 함수이기 때문에 fetchThumbnail 함수는 thumbnailURLRequest 함수에게 쓰레드 제어권을 넘겨줍니다.

thumbnailURLRequest 함수는 수행에 얼마나 많은 시간이 걸리던 쓰레드를 점유하고 작업이 완료되면 제어권을 다시 Caller인 fetchThumbnail 함수에게 돌려줍니다.

이 경우 쓰레드는 이 두 작업 외의 다른 작업들을 수행할 수 없습니다.

asynchronous한 경우에는 어떨까요?

fetchThumbnail 함수가 data(for: request) 함수에게 쓰레드 제어권을 넘겨주는 것까지는 동일합니다.

하지만 await로 명시된 data(for: request) 함수는 async 함수이기 때문에 중간에 suspend 될 수 있습니다.

async 함수가 suspend되면, 쓰레드 제어권은 다름아닌 시스템에게 넘겨집니다.

그러면 시스템은 다른 작업을 할 수 있게 되는 것이죠.

시스템은 알아서 suspend 되거나 수행이 필요한 다른 작업들의 우선순위들을 판단해가며 처리해나갑니다.

시스템이 suspend 되었던 함수의 처리가 필요해졌다고 판단하는 순간, 쓰레드 제어권은 다시 async 함수였던 data(for: request) 함수에게 재개(resume)되고 이후의 작업들이 수행될 수 있게 됩니다.

자 다시 돌아가서 Suspend가 이루어지는 과정을 자세히 살펴볼게요.

Synchronous한 함수의 경우 메모리의 스택 영역에 함수들이 push 되며 쌓이게 됩니다.

그러다가 함수의 실행이 끝나면 pop 되어 스택에서 제거되죠.

아주 간단명료합니다.

그러면 asynchronous한 경우에는 어떨까요?

async 함수라고 명시되어 있는 경우, scope 전체를 한 번 돌며 suspension point (await) 마다 어떤 변수가 여러 쓰레드에서 사용되는지를 파악합니다.

예시의 경우, id와 particle은 쓰레드 사이를 오갈 필요가 없는 local 변수이죠?

따라서 해당 변수들은 synchronous 함수의 경우와 마찬가지로 스택 영역에 저장됩니다.

그렇다면 await에서 사용된 newArticles 변수*(파라미터로 받았기 때문에 상수이지만 편의상 변수라고 하겠습니다.)*의 경우는 어떨까요?

suspend되는 코드는 잠깐 멈춰있다가 다시 실행되야하기 때문에 필요한 변수들을 멈추기 이전과 이후 모든 시점에 사용할 수 있어야 합니다.

Swift는 이를 위해 Heap 영역을 활용합니다.

add 함수를 힙 영역에 저장하고 나면 스택 영역에는 해당 프레임을 계속 붙잡고 있을 필요가 없기 때문에 실행이 필요한 save 함수로 대체됩니다.

이 save 함수 안에 마찬가지로 await 코드가 담겨있다고 가정해보면, 해당 save 함수 또한 힙 영역으로 옮겨진 후 시스템에 쓰레드 제어권을 넘겨주게 됩니다.

쓰레드는 다른 작업들(otherWork1, otherWork2)을 마찬가지로 힙 영역에 보관하며 수행합니다.

따라서 힙 영역에는 async 함수들의 스택들이 모여있게 되는 것이죠.

Continuation이라는 것이 이런 힙 영역의 async 스택을 대표한다고 합니다.

Continuation이란 단순히 await 이후에 수행되는 작업들을 표현하는 말이라고 합니다.

withCheckedThrowingContinuation(continuation:)과 같은 메서드에서 사용되니 참고해주세요!

작업이 없는 쓰레드가 생기고 힙 영역에 저장된 async continuation이 다음 작업으로 선택되면, 힙 영역에 있던 작업 스택을 하나씩 다시 스택 영역으로 불러와 차근차근 작업을 수행합니다.

이 때, 작업이 없는 쓰레드라는 것은 await 이전에 수행하던 쓰레드일수도 있고 아닐 수도 있습니다. 보장되지 않는다는 것이죠.

자 그래서 이 async / await를 이용한 Concurrency는 어떻게 사용하면 될까요?

Task

위의 예시를 여러번 수행하는 또 다른 예시입니다.

이 예시는 상당히 좋은 예시이고 아주 정상적으로 잘 동작하는 예시입니다.

하지만 한 가지 개선이 필요한 부분이 있습니다.

for in을 통해서 여러번의 URLSession을 await하는 것인데요.. 이런 식의 구현은 한 번에 하나의 루프만을 수행할 수 있습니다.

async하게는 구현하였지만 concurrent하지는 못한 것입니다.

또한 fetchThumbnails()이라는 함수 또한 결국에는 async 함수이기 때문에 프로젝트의 어딘가에서는 async 컨텍스트를 제공해줄 곳이 필요합니다.

이 때 Task가 등장합니다.

Task는 concurrent한 코드 수행을 위한 새로운 async 컨텍스트를 제공합니다.

async 함수를 단순히 call 하는 것은 Task를 생성하지 않습니다! (GCD 등을 사용하면 call 할 수는 있습니다.)

하지만 어떤 Task들이 있나 보기 이전에 Task Tree라는 개념을 알아두어야 합니다.

Task Tree

Task Tree는 Task의 취소(cancellation), 우선순위(priority), 지역변수(task-local variables) 등의 속성들을 결정하는 아주 중요한 개념입니다.

기본적으로는 어떤 async 함수가 다른 async 함수를 호출하면, 두 함수를 호출하는 데에는 같은 Task가 사용됩니다.

아래 async-let에서 사용된 예시의 경우를 먼저 한 번 가져와봤습니다.

fetchOne() 함수가 두 가지의 Task data와 metadata를 호출하는 경우입니다.

fetchOneThumbnail() 함수는 두 가지 Task를 child로 갖고 있다고 했습니다.

이처럼 한 Task가 다른 Task를 실행하면 실행된 Task들은 현재 함수가 실행되고 있는 Task의 Child Task가 됩니다.

Task는 함수에 종속된 개념은 아니지만 함수의 생명주기에 영향을 받을 수는 있습니다.

그리고 Parent Task는 종속된 모든 Child Task들이 종료되기 전에는 종료될 수 없습니다.

만약 metadata Task가 에러를 throw하면서 종료되었다는 상황을 가정해봅시다.

두 Task는 같은 guard 문 내에 있기 때문에 즉시 에러를 throw하고 함수를 종료할 수 있겠죠?

하지만 Task에서는 그렇지 않습니다. 정확히 말하면 “즉시” 종료하지는 않습니다.

metadata Task가 실패했더라도 data Task는 여전히 동작중일 것입니다.

따라서 해당 Task가 취소되었다는 정보를 제공해주고 Task가 종료되기를 기다렸다가 모든 Task가 종료된 시점에 함수가 종료됩니다.

여기서 취소되었다(cancelled) 라는 것은 해당 Task를 종료시키는 것이 아니고 결과가 더 이상 필요없다는 것을 알려줄 뿐입니다.

만약 취소된 Task가 Child Task를 가지고 있다면 모든 Child Task들 또한 취소됩니다.

이러한 Task Tree 동작은 ARC와 같이 실수로 벌어지는 Task Leak를 방지하기 위함이라고 합니다.

이런 Task Tree의 특성을 정리하면 다음과 같이 표현할 수 있습니다.

Task의 취소는 협력적(cooperative) 으로 이루어집니다.

1. Task는 취소되더라도 즉시 종료되지 않습니다.
2. Task의 취소 여부는 어디에서도 가능합니다. (synchronous한 코드에서도)

이는 개발자가 Task가 취소되었을 때의 동작을 구현할 수 있게 하기 위함이라고 하네요.

이 말은 Task가 오래 걸리는 동작일수록 취소에 대응하는 코드가 꼭 필요하다라는 뜻 같습니다.

설명만으로는 무슨 말인지 잘 모르겠으니 예시를 다시 가져와보죠!

위와 같이 concurrent한 동작이 수행되기 전에 Task.checkCancellation()나 if Task.isCancelled { break }을 통해 불필요한 썸네일 생성의 동작을 방지하고 에러를 방출할 수 있습니다.

위 예시의 경우 Task가 취소되었더라도 thumbnails에는 취소되기 이전에 성공한 데이터들이 담겨있고, 그 데이터들이 그대로 반환됩니다. 빈 데이터 등의 결과는 UI에 에러를 발생시킬 수 있기 때문에 염두에 두고 작업해야합니다.

이제 우리는 Task가 언제 취소되거나 완료되는지를 알았습니다! 😎

드디어 Swift가 제공하는 다양한 형태의 Task를 알아볼 때가 되었네요. 하나씩 살펴보죠!

Structured Tasks

• async-let Tasks

지금까지의 URLSession.data() 함수는 위와 같이 사용되었습니다.

화살표의 방향대로 단 한가지의 흐름(단방향)만이 존재합니다.

하지만 우리는 URLSession은 시간이 걸리는 함수이기 때문에 수행 시간동안 다른 작업들이 수행되길 원합니다.

async-let을 사용하면 위처럼 흐름이 두 가지로 나뉘어집니다.

Child Task가 생성되고, URLSession.data() 함수를 async하게 실행함과 동시에 result에는 임시 값(placeholder) 을 넘겨준채로 await 키워드가 등장할 때까지 수행합니다.

await에서 기다리던 작업은 async 함수가 끝이 나면 result 값을 대체하여 사용합니다.

그렇다면 위 코드를 async-let을 사용하는 방식으로 바꾸려면 어떻게 해야할까요?

try await은 child task에게 작업을 넘겨줬기 떄문에 더 이상 해당 함수를 호출하는 지점에서는 필요가 없습니다.

Parent task에서 결과로 나온 변수를 사용할 때 필요하죠.

따라서 다음과 같이 바꿔줄 수 있습니다.

각각의 URLSession에서 try await을 제거하는 대신 맨 앞에 async를 붙여주고,

Parent task인 fetchOneThumbnail() 함수에서 data와 metadata가 필요한 순간에 try await 을 사용하고 있습니다!

• Group Tasks

async-let은 수행해야하는 Task의 개수가 정해져있을 때 유용합니다.

다시 한번 위 예시의 경우를 보면, 몇 개의 썸네일을 생성하던지 간에 fetchOne이라는 Task는 고정적으로 두 개의 Child Task를 가지고 있습니다.

하지만 id의 개수에 따라서는 수행할 fetchOne() 함수가 실행될 Task의 개수는 달라지겠죠?

Task Group은 이런 경우에 유용합니다.

Task Group은 동적 개수의 Task의 수행이 동시에 필요할 때 사용되기 위해 고안되었습니다.

withThrowingTaskGroup(of:) 를 통해서 Task Group을 만들어줄 수 있습니다.

이 함수는 Child Task를 생성하는 group 이라는 인스턴스를 사용하는 Context를 제공합니다.

또한 for 루프의 각 루프들은 group.async를 통해 비동기적으로 수행되기 때문에 랜덤한 시기에 순서 상관 없이 수행될 수 있습니다.

group 인스턴스가 루프를 전부 돌았더라도 Task Tree의 특성에 의해 모든 Task가 종료될 때까지 await된다는 것도 알 수 있겠죠!

그런데.. 모든게 평화로워 보이는 위 코드는 놀랍게도 심각한 에러를 가집니다.. 😰

심지어 빌드도 안되는 컴파일러 에러를 내뿜죠..

바로 Data Race Issue가 발생하기 때문입니다..

Data Race Issue는 한 번에 여러 개의 Task에서 하나의 데이터에 접근할 때 발생하는 에러입니다. 하나의 변수는 한 번에 하나의 연산만 가능하지만, 여러 Task에서 동시에 값을 수정하려고 하면 크러쉬가 나거나 데이터가 손상되게 됩니다..

이 경우에는 하나의 thumbnails 딕셔너리에 여러 Task들이 동시에 값을 넣어주고 있죠?

이는 Concurrency 프로그래밍을 할 때 개발자들이 흔히 하는 실수 중에 하나입니다.

Data Race Issue의 해결은 개발자에게 달려있었습니다.

하지만 업데이트된 Swift Concurrency는 이를 컴파일러에서 미리 발견하여 에러를 발생시켜주는 것이죠! 👏 (이렇게 들으니까 멋지죠?)

그래서 에러를 잡아주긴 하는데 해결은 어떻게 해야할까요?

Task는 사실 @Sendable 클로저라는 클로저에 의해 감싸져 있습니다.

@Sendable 클로저의 캡처는 독특하게도 mutable 변수의 값을 캡처하지 못합니다.

그러면 어떤 값들을 캡처할 수 있는가 하면?

값 타입(Int, String, …) 변수, actors, 고유한 synchronization을 가진 class 를 캡처하거나 사용할 수 있습니다.

다시 예시로 돌아가서 에러를 고쳐볼게요..

thumbnails에 직접적으로 값을 대입하는 대신, String 타입과 UIImage 타입의 튜플을 반환하는 방식으로 변경합니다.

그 후에 for await 루프를 통해 순차적으로 값들을 thumbnails에 대입해주고 있습니다.

AsyncSequence 프로토콜을 채택한 값을 다루고 있다면 for await 루프를 사용해볼 것을 권장하고 있네요.

자.. 여기까지 알아본 async-let 과 Grouped Tasks는 Structured Task라는 각자의 hierarchy가 정돈된 Task들을 처리하는 방식이였습니다.

하지만 언제나 정돈된 방식을 사용할 수 있는 건 아니기 때문에 Swift는 Unstructured Tasks라는 API를 추가로 제공하고 있습니다.

Unstructured Tasks

Hierarchy가 정돈되지 않은 Task에는 어떤 Task들이 있을까요?

먼저, Parent Task가 존재하지 않을 수 있습니다. async하지 않은 컨텍스트에서 async한 Task를 시작해야할 때가 이런 경우죠.

또 Task가 하나의 scope를 넘어 여러 scope에서 이루어지도록 할 필요가 있을 때도 있을겁니다.

보통 delegate 패턴을 사용할 때 흔히 일어나는 일이라고 하네요.

위 예시를 봅시다..

delegate 함수인 collectionView(willDisplay:, forItemAt) 함수는 UI 레이어의 함수이기 때문에 async하지 않습니다.

하지만 데이터를 받아오는 fetchThumbnails() 함수는 async 함수이죠.

이럴 때가 바로 Unstructured Task를 사용할 때입니다.

간단하게 async 처리가 필요한 곳은 Task로 감싸줍니다.

런타임동안 이 Task를 생성하는 부분을 마주치게 되면, 수행하는 scope와 같은 actor에서 실행되도록 예약을 해둡니다.

예시의 경우에는 MainActor에서 실행이 될 겁니다.

이렇게 사용하기 간편하다면 단점도 당연히 있겠죠?

Task의 생명주기가 scope에 종속되지 않고 synchronous한 코드 중간에서도 호출이 될 수 있기 때문에 Structured Task에서 자동으로 수행될 수 있었던 취소와 await를 개발자가 직접 해줘야 합니다.

이 경우, Task를 생성한 뒤에 thumbnailTasks라는 딕셔너리에 저장하였습니다.

그러면 나중에도 언제든지 접근해서 작업을 취소할 수 있겠죠?

defer문을 사용해 Task가 끝난 시점에 저장된 Task를 해제함으로써 이미 완료된 Task를 취소하는 일도 방지해둔 것을 볼 수 있네요.

🙋 어라 그런데.. 같은 데이터에 여러 Task가 동시에 접근하면 안된다고 하지 않았나요?

맞습니다.. 하지만 이 경우에는 @MainActor, 즉 메인쓰레드에서 이루어지기 때문에 절대로 동시에 일어날 일이 없습니다.

셀이 화면에서 벗어나면 작업을 취소해도 되겠죠.

다음과 같이 task.cancel() 로 Task를 취소해줄 수 있습니다.

Detached Tasks

어라 뭐가 하나 또 있죠…?

Unstructured Tasks는 어떤 스코프에서도 수행될 수 있는 Task였습니다. 하지만 어떤 컨텍스트에서 시작되었는지는 중요한 요소였습니다.

해당 scope의 변수도 사용해야 하고,

Detached Tasks는 그 어떤 것도 상관이 없을 떄 사용하는 Task입니다.

Detached Tasks는 컨텍스트로부터 독립적입니다.

시작된 scope에서 아무 값도 가져오지 않습니다.

심지어 같은 actor에서 실행되도록 되어있지도 않아서 같은 우선순위를 갖지도 않습니다.

위 예시는 썸네일을 생성한 후에 로컬 디스크에 캐싱을 하는 작업을 Detached Task에서 작업하도록 하는 코드입니다.

캐싱은 @MainActor에서 처리될 필요가 전혀 없죠.

높은 우선순위를 가질 필요도 없습니다.

Task.detached(priority:) 를 통해서 간단하게 컨텍스트에서 독립된 Detached Task를 만들어줄 수 있습니다.

Detached Task에 Task Group을 사용해서 hierarchy를 만들어줄 수도 있습니다.

여러가지 백그라운드 작업이 필요하지만 연결된 작업이 필요할 때 아주 유용하겠죠!

정리

Actor

끝난 줄 알았죠..?

하지만 아직 많이 남았습니다. 🤯

위에서 Actor라는 키워드가 사용되었었죠..?

이게 뭔지도 알아봐야죠..

Actor가 뭔지 알아보려면 마찬가지로 이미 한 번 살펴본 Data Race Issue와 관련되어 있다는 것을 알고 시작해야합니다.

Data Race는 여러 개의 Task에서 동시에 하나의 mutable 값에 접근하려고 하면 발생하는 문제였습니다.

그렇다면 문제를 어떻게 해결할까요?

변하지 않는 데이터를 사용하거나 여러 Task에 걸쳐 사용되지 않도록 하면 해결되겠죠?

그러면 이렇게 하면 되겠네요!

let으로 값이 고정된 값을 각 Task에서 mutable한 값으로 복사한 뒤 작업을 해주면 되겠죠.

아뇨 안됐습니다. 🙅‍♂️

에러는 발생하지 않지만 Task마다 복사된 값은 서로의 값에 영향을 주지 못하거든요.

그러면 이렇게 정리할 수 있습니다: 각 Task들이 공유할 수 있는 mutable Task가 필요하다!

Swift는 이미 그런 feature들을 갖고 있습니다.

이런 문제는 오래된 문제거든요..

mutable state를 동기화하는 작업은 로우레벨 단계에서 사용할 수 있는 Atomics, Locks, 더 높은 레벨에서 사용할 수 있는 Serial DIspatch Queues가 있습니다.

이들은 모두 같은 역할을 하고 같은 문제를 갖고 있습니다.

Shared mutable state에 Data Race 없이 접근할 수 있지만, 사용법이 조금이라도 어긋나면 바로 앱이 크러쉬된다는 것이죠.

Actors는 이런 문제를 해결하고 shared mutable state의 동기화를 좀 더 쉽게 이룰 수 있도록 등장했습니다.

Actors는 state를 다른 모든 프로그램에서 분리하여 관리합니다.

그리고 해당 state에 접근하려면 무조건 actor 내부에 들어가야만 하죠.

Actor는 조금 특이하게 사용됩니다.

새로운 타입이거든요.

마치 struct, enum, class와 같이 프로퍼티, 메서드, 생성자 등을 가집니다.

protocol과 extension 또한 사용할 수 있습니다.

또, actor는 shared mutable state에 접근하기 위해 만들어진 만큼 class와 같은 참조 타입입니다.

사용법은 class와 동일합니다.

한 가지 주의할 점이 있다면 class와는 다르게 상속을 지원하지는 않습니다!

그리고 가장 중요한 점은 actor에서 정의된 값들은 동시에 접근되지 않도록 보장되어 있다~라는 점입니다.

위의 예시에 적용해보면 이렇게 됩니다.

같은 값에 접근하지만, 절대 동시에 접근할 수는 없기 때문에 순서대로 2, 1이나 1, 2가 출력될겁니다.

하지만 suspend된 작업이 actor 안에서 얌전히 차례를 기다릴 것이라는 보장은 되는 걸까요?

우리는 이미 그런 역할을 하는 키워드를 알고 있습니다.

actor의 외부에서는 await 키워드를 통해 해당 작업이 suspendable하다는 것을 명시해줄 수 있습니다.

하지만 actor의 내부에서는 이와 같은 키워드는 필요가 없죠.

모든 코드가 synchronous하게 실행되기 때문에 동시성 프로그래밍의 문제를 신경쓰지 않고 작업할 수 있습니다.

Actor Reentrancy

위 코드는 이미지를 캐싱하는 작업을 수행하는 actor입니다.

문제는 await에서 발생합니다.

이미지를 다운로드하는 과정은 시간이 오래 소요되는 작업이니 await을 사용하는 것은 올바른 접근입니다.

하지만 동시에 두 군데에서 같은 url의 이미지를 받아오길 원하고, 하나의 작업이 수행되는 동안 서버의 이미지가 교체되는 상황이 있다면 어떻게 될까요?

두 작업은 동시에 요청됐음에도 불구하고 다른 이미지를 받아오게 될겁니다.

이 경우에는, 이미 url에 해당하는 이미지가 있다면 그 이미지를 불러와 사용하고, 없다면 새로운 이미지를 넣는 것으로 해결하였습니다.

이와 같이 actor 내부에서 await을 사용하는 것은 숨겨진 버그를 유발할 수 있기 때문에 주의가 필요합니다.

이런 과정을 actor에 재진입하여 작업을 수행한다고 해서 Actor Reentrancy라고 부릅니다.

다음 세 가지를 항상 생각해가며 코드를 짜봅시다.

1. 되도록 synchronous하게 데이터를 mutate 시킨다.
2. await에서 suspend된 동안 state가 바뀔 수 있음을 생각한다.
3. await 후에 조건문 등을 통해 state가 예상범위 안인지 체크한다.

Actor Isolation

Actor는 다른 프로그램들과 독립적으로 있는 존재라고 했었죠?

따라서 외부에서 actor에 접근할 떄는 이런 독립성을 해치면서 접근할 수는 없습니다.

여기서부터 조금 아득해집니다.. 주의하세요… 🫠

• Protocol

이 경우 Equatable 메서드는 static 이고 파라미터로 받는 두 actor 타입 값의 외부에 있으니까 가능한 문법입니다.

반면 이 경우에는 허용되지 않습니다.

hash(into:) 함수는 actor 내부에 들어가고, async하지도 않기 때문입니다.

하지만 이상한 점이 있습니다. 😕

actor 내부에 들어가는 것은 맞지만, 실제로 actor가 갖고있는 값을 변경하는 것은 아니거든요..

그런 경우에는 nonisolated 키워드를 붙여 해결할 수 있습니다.

하지만 끝이 아닙니다..

이 경우에는 사용하는 actor의 프로퍼티 idNumber가 immutable한 값이거든요.

하지만 mutable한 값을 사용하려고 하면…?

어김없이 에러가 발생합니다.

외부에서 mutable한 값에 접근하는 것은 Data Race를 유발할 수 있거든요.

• Closure

이번에는 클로저 안에서 실행되는 함수의 경우를 살펴봅시다.

위 예시는 아무 문제가 없습니다.

독립된 공간에 있는 read() 함수 안에 있는 (마찬가지로 독립된 공간에 있는) readSome() 함수가 synchronous하기 때문에 순차적으로 실행되기 때문이죠!

그렇다면 이 경우는 어떨까요..

Detached Task에 read() 함수가 있기 때문에 이 경우에는 클로저 안의 작업들이 독립된 공간에 있지 않고 밖으로 나가게 됩니다.

때문에 해당 클로저는 actor에 있지 않고, await 키워드를 붙여 비동기적으로 처리되어야 합니다.

자 이 경우를 봅시다..

Book이라는 인스턴스는 class 타입입니다. 참조 타입이니까 actor 안에 있지 못하고 외부에 위치해있죠.

actor 안에 참조 타입의 값이 있는 것 자체는 아무 문제가 없습니다.

문제는 해당 값에 접근을 할 때 발생하겠죠? (Data Race)

여기서 익숙한 키워드가 등장합니다.

Sendable

Sendable 타입은 다른 여러 actor들 사이에서 함께 사용될 수 있는 타입입니다.

어떤 값을 각자의 actor로 복사하고, 복사된 값을 독립적으로 처리할 수 있다면 해당 값은 Sendable하다고 할 수 있습니다.

값 타입과 Actor 타입은 기본적으로 Sendable합니다.

하지만 클래스(참조 타입) 의 경우에는 고려해야할 사항이 있죠..

1. 클래스에 있는 모든 값들이 immutable(let) 한 경우
2. 클래스 내부적으로 동기화(NSLock, ...)를 구현한 경우

하지만 대부분의 클래스는 그렇지 않기 때문에 Sendable이 아니라고 할 수 있습니다.

함수는 기본적으로는 Sendable하지 않지만 @Sendable 함수와 같은 새로운 타입의 함수를 사용하면 Sendable합니다.

Sendable은.. 예상하셨겠지만 사실 프로토콜입니다.

Swift에서 concurrent한 작업을 하기 위해서는 Sendable 프로토콜을 준수한 값들을 사용해야하는 것이죠..!

자.. 다시 클로저로 돌아가봅시다.

클로저가 Sendable하려면 어떤 경우여야 할까요?

간단합니다. 클로저가 캡처하는 모든 값들이 Sendable해야하죠.

또 캡처한 값들이 mutable(var) 하면 안됩니다.

그러면 Data Race가 발생할테니까요..

마지막으로 클로저가 synchronous한 경우에 actor에서 독립된 형태이면 안됩니다.

외부에서 접근이 가능해지니까요!

Main Actor

마지막으로 살펴볼 게 있습니다.

Main Actor라는 특수한 actor인데요, 이미 전에 한 번 언급된 적이 있었죠?

백그라운드에서 작업을 하다가 다시 메인쓰레드로 넘어와 UI를 업데이트해야 하는 상황..

아주 익숙하죠?

DispatchQueue.main.async {
  updateButton()
}

보통 위와 같이 DispatchQueue.main을 사용해오곤 했습니다.

@MainActor는 해당 작업이 메인쓰레드에서 이루어져야 한다는 것을 명시하는 키워드입니다.

DispatchQueue.main 대신 사용하여 명시적으로 메인쓰레드에서 동작해야한다는 것을 컴파일러에게 알려줍시다..!

References

WWDC21 - Swift concurrency: Behind the Scenes

WWDC21 - Explore structured concurrency in Swift

WWDC21 - Protect mutable state with Swift actors

naljin - Swift async / await & concurrency