[WWDC 2021] Protect mutable state with Swift actors

이번 세션에는 await/async 에 이어 새롭게 등장한 Actor 타입에 대해 자세히 소개합니다 !!

https://developer.apple.com/videos/play/wwdc2021/10133/

Protect mutable state with Swift actors - WWDC21 - Videos - Apple Developer

 

Actor in swift 

첫번째로, actor가 등장하게 된 이유에 대해 소개합니다.

concurrent 프로그램을 작성할때 고려해야 할 근본적인 문제 중 하나는 data racing을 피하는 것이죠. data racing은 두 쓰레드가 동시에 같은 데이터에 접근시 and 둘 중 하나가 쓰기 작업을 하고 있을때 발생합니다. 

 

아래 안좋은 예시 코드를 봅시다.

시간의 흐름에 따라 1, 2 또는 2,1의 값을 얻을 수 있습니다. 이것은 counter가 안정적인 state에 남겨져 있을때 경우입니다.

하지만 두 task 모두 0을 읽고 1을 써서 1,1의 결과값을 얻을 수도 있고 값이 증가된 후에 return된다면 둘다 2, 2를 읽을 수도 있습니다.
data racing은 피하고 디버그하기가 매우 어렵기로 악명이 높습니다. 

 

data racing은 shared mutable state에 의해 발생됩니다.(위 예시에서는 value state가 될 것입니다.)

만약 data가 변화하지 않거나 여러 concurrent task에 공유되지 않는다면 data racing이 발생하지 않을 것입니다. 
data racing을 피하는 방법 중 하나는 value semantics를 사용해 shared mutable state를 제거하는 것입니다.  다양한 value type과 함께 모든 mutation은 지역적입니다. 더욱이 let value semantic 타입의 프로퍼티는 immutable하므로 다른 concurrent task로부터 안전합니다. 

예시를 봅시다. array1은 int 타입의 array입니다. 그리고 array2에 첫번째 array1 값을 copy합니다. 그리고 각 배열에 값을 append 합니다. 그리고 출력해보면 ?
//array1 = [1,2,3]
//array2 = [1,2,4]
가 할당 될 것입니다. 

 

그러면 value type인 struct로 바꾸면 어떻게 될까요 ? 또한 increment 함수를 mutating으로 바꾸었습니다. 

헐랭 그러면 컴파일 에러가 발생합니다. 
counter가 let이기 때문이죠. 그래서 let을 var로 바꾼다면 counter가 두 concurrent task에 의해 참조되기 때문에 다시 race condition이 발생할 것입니다. 

다행이도 컴파일러가 불완전한 코드에 대해 에러 메세지를 보여줍니다. 

 

따라서 각 concurrent task에 대해 로컬 mutable 변수를 내부에 넣어줌으로서(지역적으로) 해결 할 수 있습니다. 
이를 실행하면 각 concurrent task에 대해 항상 1을 프린트하게 됩니다. 

 

그러나 우리의 코드는 이제 race condition으로부터 자유롭지만 그 행동은 더 이상 우리가 원하는 것이 아닙니다. 이것은 공유 변경 가능 상태가 필요한 경우가 여전히 있음을 보여줍니다.

우리의 concurrent 프로그램에 shared mutable state가 있을때 이것이 race condition이 되지 않도록 보장하기 위해 synchronization의 형태를 필요로 합니다.
atomic과 locks과 같은Low level tool로부터 serial dispatch queue와 같은 고수준의 construct까지 synchronization를 위한 다양한 방법이 있습니다.

이러한 방법들은 각각은 다양한 장점을 가지고 있지만 모두 동일한 치명적인 약점을 공유합니다. 매번 정확히 정확하게 사용하려면 세심한 훈련이 필요합니다. 그렇지 않으면 데이터 경쟁으로 끝날 것입니다.

 

이것을 해결하기 위한 방법으로 Actor가 등장합니다. Actor는 swift를 위한 새로운 타입입니다. 
그들은 Swift의 모든 이름을 가진 type과 동일한 기능을 제공합니다.
actor는 properties, methods, initializer, subscripts 등등을 가질 수 있습니다. protocol를 순응하거나 extension을 가질 수 oo

또한 class와 같이 reference type입니다. 하지만 상속 지원 x

actor의 목적으로 shared mutable state를 나타내는 것이기 때문입니다. 

실제로 actor type의 주요 구별되는 특징은 인스턴스 데이터를 프로그램의 나머지 부분과 분리하고 해당 데이터에 대한 동기화된 액세스를 보장한다는 것입니다.

예시를 봅시다. 여기에는 actor type의 Counter가 있습니다. 
struct와 class와의 차이점은 actor는 value가 동시적으로 접근되지 않음을 보장한다는 것입니다. 
이 예시에서 increment 메서드는 호출될때 actor에서 실행되는 다른 코드없이 호출될 것이라는 것입니다. 이것은 actor state에 대한 잠재적인 data race가 없음을 보장하게 합니다. 

우리는 같은 counter에 increment 메서드를 호출하는 두 concurrent task가 있습니다. 
액터의 내부 동기화 메커니즘은 하나의 increment 호출이 다른 호출이 시작되기 전에 완료될 때까지 실행되도록 합니다. 그러므로 우리는 1 -> 2 또는 2 -> 1의 값을 얻을 것입니다. 
어떻게 두번째 task가 잠재적으로 actor에 기다릴 것을 보장 할 수 있을까요 ? swift는 이에 대한 메커니즘을 가지고 있습니다. 

 

이 resetSlowly 메서드는 카운터 액터 유형의 확장에 정의되어 있으므로 액터 내부에 있습니다. 즉, 카운터 값을 0으로 재설정하기 위해 수행하는 액터의 상태에 직접 액세스할 수 있습니다.
Actor에서 실행 중임을 이미 알고 있기 때문에 대기가 필요하지 않습니다.
이것은 actor의 중요한 특징입니다. 
Actor의 동기 코드는 중단 없이 항상 완료될 때까지 실행됩니다.

동기 코드는 중단 없이 실행되지만 Actor는 종종 서로 또는 시스템의 다른 비동기 코드와 상호 작용한다고 강조했습니다. 
비동기 코드와 Actor에 대해 이야기해 보겠습니다.

ImageDownloader actor에 대해 예시를 봐 봅시다. 이미 다운로드 된 image가 있다면 cache에서 리턴하도록 하며 없다면 다운로드 된 image를 cache에 저장하여 리턴하도록 하고 있습니다. 

액터의 동기화 메커니즘은 한 번에 하나의 작업만 캐시 인스턴스 속성에 액세스하는 코드를 실행할 수 있도록 보장하므로 캐시가 손상될 수 있는 방법이 없습니다.
즉 여기서 await 키워드는 await가 발생할때마다 downloadImage함수가 이 시점에 중단될수 있음을 나타냅니다. 따라서 CPU가 다른 프로그램을 실행할수 있도록 잠시 놔두죠. 함수가 다시 재개되면 전반적인 프로그램 state가 변경 되어 있을지도 모릅니다. 

Await 후에 유지되지 않을 수 있는 await 이전 상태에 대해 가정하지 않았는지 확인하는 것이 중요합니다.
우리가 동시에 같은 image를 가져오는 두 다른 concurrent task를 가지고. 있다고 상상해봅시다. 

자, 첫번째 Task1은 cache 저장소에 image가 없음을 확인하고 downloadImage하기 시작합니다. 

downloadImage 함수는 오래 걸리기 때문에 suspend됩니다.  

첫번째 Task1가 image😸를 다운로드 하는 도중 새 이미지😿가 같은 url로 서버에 적용될 수 있을것입니다.

자 이제 task2가 image를 가져오길 시도합니다. 아직 task1에서 이미지 다운로드가 끝나지 않았기 때문에, cache 딕셔너리에서 이미지를 찾지 못할 것입니다. 

그리고 task2 역시 downloadImage하는 동안 suspend 됩니다. 

그 후에 첫번째 task1이 다운로드를 마치고 actor에서 실행을 재개합니다.
cache에 받아온 이미지를 저장하고 return 하겠죠 ?

그리고 두번째 task2 역시 다운로드를 마치고 url에 image를 저장하고 return 할 것입니다. 
우리가 첫번째 task1을 통해 이미 image를 cache에 저장했음에도 불구하고 task2가 image를 다시한번 갱신하면서 두번의 네트워크 호출이 발생했습니다. 
Await 키워드와 함께 잠재적인 bug가 발생할 가능성이 있습니다. 
여기서 수정하기 위해서 await 후 가정을 확인하는 것입니다.

task를 재개(resume)할때, cache에 이미 데이터가 있다면 우리는 원래 image을 유지하고 새 image을 버립니다. 

가장 좋은 솔루션은 중복 다운로드를 완전히 피하는 것입니다. 

actor의 재진입은 교착 상태를 방지하고 앞으로의 진행을 보장하지만 각 대기에서 가정을 확인해야 합니다.
재진입을 위한 디자인을 하기 위해서 동기 코드 안에서 actor state의 mutation을 수행합니다. state mutation은 일시적으로 actor를 일관성 없는 상태로 만드는 것을 포함할 수 있습니다. 

await 전에 일관성을 복원해야 합니다. await는 잠재적인 suspension point임을 기억하십시오. 만약 코드가 suspend된다면 프로그램은 코드가 재개되기 전까지 움직일 것입니다. 전역 sate, clock, timer 또는 actor에 대해 만든 모든 가정은 await 후에 확인해야 합니다. 

Actor isolation은 actor type의 행동에 가장 근본적인 것입니다. 

LibraryAccount actor에 대해 살펴보겠습니다
== 메서드는 static 타입으로 actor에 isolate되지 않습니다.  Equatable 프로토콜을 순응하는 == 메서드는 actor type의 두 매개변수가 있으며 이 static 메소드는 둘 다 외부에 있습니다. actor에 오직 immutable state만 접근하고 있으므로 괜찮습니다. 

(isolate라는 의미가 지역적(local)? 이랑 일맥상통하는지 모르겠습니다 .. 🤔)

 

이번엔 Hashable 프로토콜을 순응하는 경우를 봅시다. Hashable은 hash 함수 구현을 필요로 하는데 컴파일 에러가 발생하네요. Hashable을 순응하는 이 actor는 actor 밖에서 이 함수가 호출될 수 있음을 의미합니다. 하지만 hash함수는 async하지 않습니다. 그러므로 actor isolation을 유지할 방법이 없습니다. 이것을 수정하기 위해서 우리는 함수를 non-isolation으로 만들 수 있습니다. 

isolation에 대한 개념이 헷갈려 zedd님 정리 글을 참고했습니다 -> https://zeddios.tistory.com/1303

 

actor내에 정의된
- stored, computed instance properties
- instance methods
- instance subscripts
는 기본적으로 모두 actor-isolated 상태이다.

특1. actor-isolated 정의들은 다른 actor-isolated 정의들을 자유롭게 참조 할 수 있다.
특2. actor-isolated가 아닌 정의들은 actor-isolated 정의들에 동기적으로 접근할 수 없다. 

 

그러므로 위의 예시에서 func hash()는 actor-isolated인데 actor-non-isolated인 Hasher에서 actor-isolated인 idNumber에 접근할 수 없다는 것이지요 ! 다시 이어가봅시다.

 

Non-isolated는 actor 외부에 있는 것으로 처리되기 때문에 actor의 변경 가능한 상태를 참조할 수 없습니다. nonisolated 키워드를 붙이면 이 메서드는 변경할 수 없는 idNumber를 참조하기 때문에 괜찮습니다.
다른 프로퍼티로 hash하길 시도한다면 예를 들어 booksOnLoan과 같은 프로퍼티로 말이죠. 그렇담 컴파일 에러가 발생합니다. 왜냐하면 mutable state(var)에 대한 접근은 data race를 발생시키기 때문입니다. 

 

자, 클로저에 대해 얘기해봅시다. 함수와 같이 클로저는 isolated 될 수도 non-isolated 될 수도 있습니다. 

readSome 클로저는 read()라는 actor-isolated 함수에서 만들어진 클로저이기 때문에 역시 actor-isolated이며 await가 없음에 주목하시길 바랍니다.

또 다른 예시를 봅시다. Task.detached는 actor가 수행하는 다른 작업과 동시에(async) 클로저를 실행합니다. 그러므로 read()는 actor안에 있을 수 없습니다. 그러므로 이 클로저는 non-isolated입니다. 
Read 메서드를 호출하길 원할 때, await를 붙여 비동기적으로 호출되도록 해야 합니다. 

 

우리는 코드가 actor의 밖에서 실행되는지 아니면 안에서 실행되는지에 따라 isolation에 대해 이야기 했습니다. 이번에는 actor isolation과 data에 대해 이야기 해봅시다.

Book은 struct타입입니다. 이는 LibaryAccount actor의 인스턴스에 대한 모든 상태가 자체 포함됨을 의미합니다. (값 복사 타입으므로 ) 따라서 계속해서 이 메서드(visit)를 호출하여 읽을 책을 무작위로 선택하면 읽을 수 있는 책의 복사본을 얻게 됩니다.

책 사본에 대한 변경 사항은 actor에게 영향을 미치지 않으며 그 반대의 경우도 마찬가지입니다.
하지만 Book을 class 타입으로 만든다면, 달라지는 점이 있습니다. 

 

LibraryAccount actor는 이제 Book class의 참조타입입니다. 
하지만 그 자체로 문제는 아니지만, selectRandomBook() 메서드를 호출할때 무슨 문제가 발생할까요 ? Mutable state의 actor에 참조하기 때문에 actor의 밖에서 공유되어집니다. 이것은 잠재적인 data race condition을 발생할 수 있습니다.

이제 책의 제목을 업데이트하면 액터 내에서 액세스할 수 있는 상태에서 수정이 발생합니다. 방문 방법이 actor 내에 있지 않기 때문에 이 수정은 결국 data race condition이 될 수 있습니다. 

value 유형과 actor는 동시에 사용하는 것이 안전하지만 class는 여전히 문제를 일으킬 수 있습니다.
이를 해결하기 위해 Sendable을 사용합니다. 

Sendable type은 다른 actor 간에 값을 공유할 수 있는 type입니다.
한 곳에서 다른 곳으로 값을 복사하고 두 위치가 서로 간섭하지 않고 해당 값의 복사본을 안전하게 수정할 수 있는 경우 유형은 Sendable이 될 수 있습니다.
1. value 타입은 각 복사본이 독립적이므로 Sendable입니다.

2. Actor 타입 역시 mutable state에 대해 동기적인 접근을 보장하므로 sendable입니다.

3. class는 주의깊게 다뤄지면 sendable 타입이 될 수 있습니다. 예를 들어 만약 class와 모든 subclass가 immutable data를 가지고 있다면 sendable이 될 수 있습니다. 
4. 또는 class가 내부적으로 비동기를 수행한다면 따라서 concurrent에 안전한 접근을 보장한다면 sendable이 될 수 있습니다. 

그러나 대부분의 클래스는 이들 중 어느 것도 아니며 Sendable이 될 수 없습니다.
5. 함수는 반드시 Sendable이 아니므로 액터 간에 안전하게 전달할 수 있는 함수에 대한 새로운 종류의 함수 유형이 있습니다. 이는 다시 살펴보도록 하죠

actor는 주로 Sendable type 측면에서 통신해야 합니다.  왜냐하면 sendable 타입은 data race를 막기 때문이죠.
이것은 Swift가 결국 정적으로 검사를 시작할 속성입니다.

그리고 non sendable 타입에 대해서 컴파일 에러를 발생시킵니다. 

 

Sendable protocol을 채택하면 swift가 자동으로 sendable 조건에 부합하는제 체크 할 것입니다. 

 

Author은 클래스 타입으로 sendable 타입이 아닙니다 따라서 컴파일 에러를 일으키죠.

 

제네릭 타입에 대해선 인자에 따라 달려 있습니다.

 

아까 말했던 함수가 sendable이 될 수 있는 경우를 고려해봅시다.
함수 자체는 Sendable이 될 수 있습니다. 즉, 액터 간에 함수 값을 전달하는 것이 안전하다면 말이죠. 이는 클로저가 data race condition을 방지하는 데 도움이 되는 작업을 제한하는 클로저에 특히 중요합니다.
예를 들어 sendable closure는 mutable 지역 변수를 capture하지 못합니다. sendable이 된다면 이러한 것이 가능해집니다. 
동기식 Sendable 클로저는 actor를 isolated할 수 없습니다. 그래야 외부에서 actor에서 코드를 실행할 수 있기 때문입니다.

 

사실 Task.detached에는 sendable 타입을 가집니다..! (왜 이제 알려주는거니 !!)

detached가 sendable임을 보장하는 클로저이기 때문에 counter struct에 mutable 함수인 increment를 호출시 에러가 발생했던 것입니다.

 

아까 보았던 또 다른 예시입니다. detached가 sendable이므로 actor에 isolated 되어야 한다는 것을 압니다. 그러므로 detached안에 작업은 비동기여야 합니다. 

Sendable type과 클로저는 actor가 isolation 되는데 도움을 줍니다. 

마지막으로 특별한 actor인 main actor에 대해 이야기 해봅시다 !
Main thread에서 하는 일은 다음과 같습니다. 

이 코드의 구조는 모호하게 친숙해 보입니다. 사실, 메인 스레드와 상호작용하는 것은 액터와 상호작용하는 것과 매우 비슷합니다. 이미 메인 스레드에서 실행 중임을 알고 있다면 UI 상태에 안전하게 액세스하고 업데이트할 수 있습니다. 메인 스레드에서 실행하지 않는 경우 비동기적으로 상호 작용해야 합니다. 이것은 actor가 작동하는 방식입니다. 

 

우리는 메인 액터라고 부르는 메인 스레드를 설명하는 특별한 액터가 있습니다.메인 액터는 메인 스레드를 나타내는 액터입니다. 두 가지 중요한 점에서 일반 배우와 다릅니다. 먼저 주 액터는 주 디스패치 대기열을 통해 모든 동기화를 수행합니다. 즉, 런타임 관점에서 주 액터는 DispatchQueue.main을 사용하여 교체할 수 있습니다.

 

둘째, 메인 쓰레드에 있어야 할 코드와 데이터가 여기저기 흩어져 있습니다. SwiftUI, AppKit, UIKit 및 기타 시스템 프레임워크에 있습니다. 자체 view, viewController 및 data model의 UI 부분에 걸쳐 있습니다. Swift 동시성을 사용하면 선언을 주 액터 속성으로 표시하여 주 액터에서 실행되어야 한다고 말할 수 있습니다.

 

이 세션에서 우리는 actor isolation를 사용하고 serial하게 작동하기 위해 actor 밖에서 비동기 액세스를 요구함으로써 actor가 동시 액세스로부터 mutable state를 보호하는 방법에 대해 이야기했습니다. 
actor를 사용하여 Swift 코드에서 안전하고 동시적인 추상화를 구축하십시오.

Value type과 actor는 함께 작동하여 data race condition을 제거합니다. 자체 동기화를 처리하지 않는 클래스와 변경 가능한 공유 상태를 다시 도입하는 기타 비전송 유형에 주의하십시오. 마지막으로 UI와 상호 작용하는 코드의 주 액터를 사용하여 주 스레드에 있어야 하는 코드가 항상 주 스레드에서 실행되도록 합니다. 자체 애플리케이션 내에서 액터를 사용하는 방법에 대해 자세히 알아보려면 Swift 동시성을 위한 앱 업데이트 세션을 확인하세요. 그리고 액터를 포함한 Swift의 동시성 모델 구현에 대해 자세히 알아보려면 “비하인드 스토리” 세션을 확인하세요. 액터는 Swift 동시성 모델의 핵심 부분입니다. 비동기/대기 및 구조화된 동시성과 함께 작동하여 정확하고 효율적인 동시 프로그램을 쉽게 구축할 수 있습니다. 

 

와.. 설명이 정말 길었습니다.

swift-evolution/Actors <- evolution 글들도 한번 살펴보고 다시 복습이 필요할 듯 합니다 .. 화이팅 ..!

swift-evolution/Actors-isolation-control 

swift-evolution/golbal-Actors 

swift-evolution/sendable