• 동시성 프로그래밍에서 데이터 경합이 발생할 수 있다.
  • 두 개 이상의 스레드가 같은 데이터에 접근하고
  • 그 중 1개 이상이 쓰기 연산일 때 발생한다.

class Counter {
	var value = 0

	func increment() -> Int {
		value = value + 1
		return value
	}
}

let counter = Counter()

asyncDetached {
	print(counter.increment())
}

asyncDetached {
	print(counter.increment())
}

• 데이터 경합은 피하기도 어렵고 디버그하기도 어렵다.
  • 프로그램의 각각 다른 영역에서 동시 접근이 일어나서 특정하기 쉽지 않고
  • 비결정적이다.(실행시마다 결과가 달라진다)
• 이게 생기는 원인은 shared mutable state가 존재하기 때문이다.
  • immutable 하거나 share하지 않는다면 문제는 생기지 않는다.
• value semantic으로 이를 막을 수 있다.

var array1 = [1, 2]
var array2 = array1

array1.append(3)
array2.append(4)

print(array1) // [1,2,3]
print(array2) // [1,2,4]

• 하지만 var로 만들고 mutating메소드를 호출하면 의미없는 일이다. 그래도 async는 이 상황에서 에러를 내준다.

struct Counter {
	var value = 0

	mutating func increment() -> Int {
		value = value + 1
		return value
	}
}

var counter = Counter()

asyncDetached {
	print(counter.increment()) // error!
}

asyncDetached {
	print(counter.increment()) // error!
}

• 복사본을 만드는 방법도 있지만, 이건 원하는 게 아니다. 즉, shared mutable state는 어쩔 수 없이 필요한 부분이 있다.

• shared mutable state는 synchronization이 필요하다.

  • 저수준 도구
    • Atomics
    • Locks
  • 고수준 도구
    • Serial Dispatch queues

• 위 도구들은 각자의 장점을 가지고 있지만, 결국 원칙대로 쓰도록 주의하지 않으면 문제가 일어날 소지가 있다는 결정적인 약점이 있다.

• 이 문제를 해결하기 위해 Actor를 도입했다.

  • Actor는 shared mutable state를 다루기 위한 타입이다.
  • Actor는 자신의 상태를 프로그램의 다른 영역과 분리한다.
  • 이 상태에 접근하는 것은 Actor를 통하는 방법뿐이다.
  • Actor는 상호 배제적인 접근을 언어 차원에서 보장한다.

• Actor Type

  • 스위프트의 다른 타입들과 유사한 기능들을 제공한다.(프로퍼티, 메소드, 생성자, 첨자 등)
  • 참조 타입
  • 다른 점은 동기화와 데이터 분리다. 액터의 모든 데이터와 메소드는 동시에 호출되지 않는다.
    • 다만 여전히 순서는 보장되지 않는다.

  actor Counter {
  	var value = 0
  
  	func increment() -> Int {
  		value = value + 1
  		return value
  	}
  }
  
  var counter = Counter()
  
  asyncDetached {
  	print(await counter.increment())
  }
  
  asyncDetached {
  	print(await counter.increment())
  }
  

  • actor의 메소드 내에서 다른 메소드를 호출할 때는 synchronous하게 호출하기 때문에 await가 필요없다.

  extension Counter {
  	func resetSlowly(to newValue: Int) {
  		value = 0
  		for _ in 0..<newValue {
  			increment()
  		}
  		assert(value == newValue)
  	}
  }
  

  • actor reentrancy: 같은 actor에 대해서 두번 호출할 때
    • 상태 변경 코드는 동기적으로 수행해야 한다.
    • await 기점으로 상태가 달라질 수 있음을 인지해야 한다.(suspention 지점에서 actor에 다른 명령이 실행될 수 있음). 그래서 전역 상태는 await이전과 이후로 체크해야 한다.

  actor ImageDownloader {
  	// actor 내에서 사용되기 때문에 데이터 경합 문제에서 자유롭다.
  	private var cache: [URL: Image] = [:]
  	
  	func image(from url: URL) async throws -> Image? {
  		if let cached = cache[url] {
  			return cached
  		}
  		
  	 // 여기서 작업이 끝날때까지 멈추고, 다른 작업이 수행된다.
  	// 이 때 이 메소드가 한번 더 호출되면, cache는 여전히 빈 상태라 요청이 한번더 가게 된다.
  	// 만약 이 때 서버에서 이미지를 갈아끼웠다면, 어떤게 먼저 끝날 지 알 수 없다.
  		let image = try await downloadImage(from: url)
  
  		// cache[url] = image
  		cache[url] = cache[url, default: image] // 먼저 들어간 이미지를 보전한다.
  		return image
  	}
  }
  

  • Actor isolation → 코드가 actor 안에서 호출되는가 바깥에서 호출되는가?

    • actor도 프로토콜 채택이 가능하다. 다만 격리를 보장할 수 없다고 판단되면 컴파일러가 오류를 낸다.

       actor LibraryAccount {
      	let idNumber: Int
      	var booksOnLoan: [Bool] = []
      }
      
      extension LibraryAccount: Equatable {
      	static func ==(_ lhs: LibraryAccount, _ rhs: LibraryAccount) {
      		return lhs.idNumber == rhs.idNumber // OK
      	}
      }
      
      extension LibraryAccount: Hashable {
      	func hash(into hasher: inout Hasher) {
      		hasher.combine(idNumber) // error: actor-isolated method hash(into:) cannot satisfy synchronous requirement
      	}
      }
      

    • 이럴때는 nonisolated 키워드를 붙여서 actor의 메소드지만, 격리를 하지 않도록 해줄 수 있다.

      • 하지만 이 때도 immutable 상태에 대해서만(let) 참조할 수 있다.

    extension LibraryAccount: Hashable {
    	nonisolated func hash(into hasher: inout Hasher) {
    		hasher.combine(idNumber)
    	}
    }
    

    • 클로저
      • non-escaping이면 상관없다.
      • 하지만 escaping이면 문제가 될 수 있다. 액터 바깥에서 데이터 참조가 일어날 수 있기 때문이다.
      • 이 상황에서도 value semantic으로 값을 넘기면 문제가 없다.
      • 하지만 클래스라면, 문제가 된다.
    • Sendable 프로토콜

      • 서로 다른 액터끼리 공유해도 괜찮은 타입을 나타내기 위한 프로토콜

      • 가능한 타입 → 마킹용 프로토콜이라서, 구현 요구사항은 없다. 스스로 판단해야 한다.

        • 값 타입
        • 액터 타입
        • 불변 클래스, 내부적으로 싱크를 맞추고 있는 클래스
        • @Sendable 함수 타입
          • mutable capture가 없어야 한다.
          • 캡쳐되는 값도 Sendable해야 한다.
          • synchronous와 actor-isolated는 동시에 달성할 수 없다.

      • Swift는 Sendable이 아닌 타입이 공유되는 것을 컴파일러에서 막아준다.

      • Sendable 채택

        • 값타입의 경우는 프로퍼티가 모두 Sendable이면 자동으로 체크해준다.
        • 제네릭의 경우도 조건부 채택으로 해결할 수 있다

      • 그동안 써왔던 asyncDetached도 sendable을 사용하고 있다.

        func asyncDetached<T>(_ operation: @Sendable () async -> T) -> Task.Handle<T, Never>
        

      • MainActor

        • 메인 스레드는 특별하다.
          • UI 렌더링
          • 메인 런루프 동작
        • 하지만 메인 스레드에서 모든 일을 하는 건 권장되지 않는다.
          • 그동안은 DispatchQueue.main.async로 해결해왔다.
          • 이제는 @MainActor 어노테이션으로 해결 가능하다.
        • 다른 액터와 구분되는 점
          • 모든 동기화를 main dispatchQueue를 통해서 한다. → 즉, DispatchQueue.main.async를 쓰던 곳은 모두 @MainActor를 적용할 수 있다.
          • 필요한 데이터와 코드가 여러군데 흩어져 있다.(한 액터에 정의되는게 아니라) → 필요한 곳에 @MainActor를 명시하면 된다.
        • 타입에 명시하면, 해당 객체의 모든 프로퍼티와 메소드는 메인스레드에서 동작한다.
          • nonisolated 키워드로 이를 개별적으로 제외시킬 수 있다.