07 · Thread Safety

var counter = 0

DispatchQueue.concurrentPerform(iterations: 1000) { _ in
    counter += 1        // 💥 data race
}
print(counter)          // 1000이 아니다. 그리고 매번 다르다.

// counter += 1 은 한 줄이지만 기계어로는 세 단계다
//   1. load   counter → 레지스터
//   2. add    레지스터 += 1
//   3. store  레지스터 → counter
// 두 스레드가 1을 동시에 하면 둘 다 같은 값을 읽고, 둘 다 +1 하고,
// 둘 다 쓴다 → 두 번 증가해야 하는데 한 번만 증가한다 (갱신 유실)

actor Cache {
    private var store: [String: Data] = [:]
    func contains(_ k: String) -> Bool { store[k] != nil }
    func insert(_ k: String, _ v: Data) { store[k] = v }
}

// 두 접근 각각은 actor로 보호되어 data race가 없다.
// 그런데 "검사 → 사용" 사이가 원자적이지 않다.
let has = await cache.contains(key)      // (1)
if !has {
    let data = try await download(key)   // (2) 그 사이 다른 task가 넣었을 수 있다
    await cache.insert(key, data)        // (3) 중복 다운로드 + 덮어쓰기
}

// ✅ 해법: 검사와 사용을 한 원자 단위로 묶는다 (actor 메서드 하나로)
extension Cache {
    func value(for k: String, load: () async throws -> Data) async throws -> Data {
        if let hit = store[k] { return hit }
        let v = try await load()          // ⚠️ 이 await 동안에도 재진입은 가능하다
        store[k] = v                      //    → L3에서 in-flight Task 캐싱으로 해결
        return v
    }
}

// 값 타입 + 불변 → 애초에 경합이 성립하지 않는다
struct Config: Sendable {
    let baseURL: URL
    let timeout: TimeInterval
}
let config = Config(baseURL: url, timeout: 30)   // let + 값 타입 = 걱정 없음

// 스레드마다 자기 사본을 갖게 한다
func process(_ items: [Item]) async -> [Result] {
    await withTaskGroup(of: Result.self) { group in
        for item in items {
            group.addTask { transform(item) }    // item은 값 복사 → 공유 없음
        }
        return await group.reduce(into: []) { $0.append($1) }
    }
}

// (a) GCD serial queue
final class LegacyStore {
    private var dict: [String: Int] = [:]
    private let q = DispatchQueue(label: "store")      // serial

    func value(_ k: String) -> Int? { q.sync { dict[k] } }
    func set(_ k: String, _ v: Int) { q.async { self.dict[k] = v } }
}

// (b) reader–writer: 읽기는 동시에, 쓰기는 barrier로 배타적
final class RWStore {
    private var dict: [String: Int] = [:]
    private let q = DispatchQueue(label: "rw", attributes: .concurrent)

    func value(_ k: String) -> Int? {
        q.sync { dict[k] }                              // 여러 읽기가 동시에
    }
    func set(_ k: String, _ v: Int) {
        q.async(flags: .barrier) { self.dict[k] = v }   // 쓰기는 혼자
    }
}

// (c) actor — 같은 일을 언어가 해 준다
actor Store {
    private var dict: [String: Int] = [:]
    func value(_ k: String) -> Int? { dict[k] }
    func set(_ k: String, _ v: Int) { dict[k] = v }
}

import os

// ❌ os_unfair_lock 을 Swift에서 직접 쓰는 건 위험하다
final class Bad {
    private var lock = os_unfair_lock()     // struct라서 복사될 수 있다!
    func f() {
        os_unfair_lock_lock(&lock)          // 복사본을 잠그면 보호가 안 된다
        defer { os_unfair_lock_unlock(&lock) }
    }
}

// ✅ iOS 16+ : OSAllocatedUnfairLock — 복사 문제가 없는 래퍼
final class Good: @unchecked Sendable {
    private let lock = OSAllocatedUnfairLock(initialState: [String: Int]())
    func value(_ k: String) -> Int? {
        lock.withLock { $0[k] }
    }
    func set(_ k: String, _ v: Int) {
        lock.withLock { $0[k] = v }
    }
}

// ✅ 그 이전 타깃: NSLock (조금 느리지만 안전하고 명확)
final class Safe: @unchecked Sendable {
    private let lock = NSLock()
    private var dict: [String: Int] = [:]
    func set(_ k: String, _ v: Int) {
        lock.lock(); defer { lock.unlock() }
        dict[k] = v
    }
}

actor ImageLoader {
    private var cache: [URL: UIImage] = [:]

    // ❌ 재진입 버그
    func image(for url: URL) async throws -> UIImage {
        if let hit = cache[url] { return hit }   // (1) "캐시에 없음" 확인
        let img = try await download(url)        // (2) ⚠️ 여기서 다른 task가 들어온다
        cache[url] = img                         // (3) 중복 다운로드 + 덮어쓰기
        return img
    }
}

// ✅ in-flight Task 캐싱 — 중복을 "발생 자체를" 막는다
actor SafeImageLoader {
    private var cache: [URL: UIImage] = [:]
    private var inFlight: [URL: Task<UIImage, Error>] = [:]

    func image(for url: URL) async throws -> UIImage {
        if let hit = cache[url] { return hit }
        if let running = inFlight[url] {
            return try await running.value       // 같은 요청은 같은 Task를 공유
        }
        let task = Task { try await download(url) }
        inFlight[url] = task
        defer { inFlight[url] = nil }

        let img = try await task.value
        cache[url] = img                         // await에서 돌아온 뒤 확정
        return img
    }
}

@MainActor
final class ViewModel {
    var items: [Item] = []          // MainActor에 격리된 상태

    func load() async {
        let data = await fetch()    // ← nonisolated 함수. 다른 실행기로 갈 수 있다
        items = data                // ← 다시 MainActor로 돌아와서 실행
    }

    nonisolated func pureHelper(_ x: Int) -> Int { x * 2 }  // 격리 밖
}

// 확인하는 법
@MainActor func check() {
    assert(Thread.isMainThread)                 // 결과적으로는 메인 스레드다
    MainActor.assertIsolated()                  // 정확히는 이 검사가 맞다
}

// ⚠️ 개념 차이가 드러나는 지점:
//   "메인 스레드에서 실행 중"  ≠  "MainActor에 격리됨"
//   Thread.isMainThread == true 여도 MainActor 격리가 아닐 수 있고,
//   컴파일러는 스레드가 아니라 "격리"를 기준으로 검사한다.

// 자동으로 Sendable
struct Point: Sendable { var x, y: Int }              // 값 타입 + Sendable 멤버
enum Status: Sendable { case idle, running }
final class Immutable: Sendable { let name: String; init(_ n: String) { name = n } }

// ❌ Sendable 아님 — 컴파일러가 거부한다
final class Mutable { var count = 0 }
// Task { mutable.count += 1 }   // error: capture of non-Sendable type

// ✅ @unchecked Sendable = "내가 락으로 직접 보장한다"는 선언
final class Counter: @unchecked Sendable {
    private let lock = NSLock()
    private var _count = 0
    var count: Int { lock.withLock { _count } }        // NSLock.withLock 은 iOS 16+
    func increment() { lock.withLock { _count += 1 } }
}
// iOS 16 미만이면 명시적으로
//   lock.lock(); defer { lock.unlock() }
// ⚠️ 락 없이 @unchecked 만 붙이면 "검사만 끈 것"이다.
//    이건 컴파일러를 속이는 것이지 안전해지는 게 아니다.

# ① Thread Sanitizer — 실제 data race를 런타임에 검출
#    Xcode: Scheme → Run → Diagnostics → Thread Sanitizer 체크
#    (성능이 5~15배 느려지므로 릴리즈 전 1회 정도)
swift test --sanitize=thread

# ② Main Thread Checker — 백그라운드에서 UIKit 접근 검출 (기본 켜짐)

# ③ Swift 6 컴파일 타임 검사 — 점진 도입
#    Package.swift 또는 빌드 설정에서 모듈 단위로
swiftSettings: [ .enableExperimentalFeature("StrictConcurrency") ]
#    또는 SWIFT_STRICT_CONCURRENCY = complete

// 초기: x = 0, y = 0
// 스레드 A            스레드 B
x = 1                  y = 1
r1 = y                 r2 = x

// 직관적으로 가능한 결과: (r1,r2) = (0,1), (1,0), (1,1)
// 실제로는 (0,0) 도 나온다!
//
// 왜? 각 코어의 "스토어 버퍼" 때문이다.
//   A가 x=1을 자기 스토어 버퍼에 넣고 아직 캐시에 반영하기 전에 y를 읽으면
//   B의 y=1이 아직 안 보인다. B도 대칭적으로 마찬가지.
//   → 두 쓰기가 서로에게 보이지 않은 채로 두 읽기가 일어난다.

// 이게 순차 일관성(sequential consistency)이 하드웨어 기본값이 아닌 이유이고,
// "락 없이 플래그 하나로 동기화" 같은 코드가 위험한 이유다.

// ❌ 잘 돌아가는 것처럼 보이지만 보장이 없다
final class BadFlag {
    var ready = false
    var data: [Int] = []

    func producer() {
        data = [1, 2, 3]     // (1)
        ready = true         // (2) — (1)보다 먼저 보일 수 있다!
    }
    func consumer() {
        while !ready { }     // (3) — ready만 보고
        print(data)          // (4) — data가 아직 비었을 수 있다
    }
}
// 게다가 컴파일러가 while 루프를 "ready는 안 변하네"라고 판단해
// 무한 루프로 최적화해 버릴 수도 있다.

// ✅ 동기화 프리미티브를 쓰면 "메모리 배리어"가 함께 온다
//    락/actor/atomic은 상호 배제만 주는 게 아니라
//    "여기 이전의 쓰기는 여기 이후에 반드시 보인다"는 순서 보장도 준다.
actor GoodFlag {
    private var data: [Int] = []
    func produce() { data = [1, 2, 3] }
    func consume() -> [Int] { data }
}

// 두 스레드가 서로 다른 변수를 만지는데도 느려지는 경우
final class Counters {
    var a = 0       // 이 둘이
    var b = 0       // 같은 캐시 라인(64B 또는 128B)에 들어간다
}

// 스레드 1: counters.a += 1  을 반복
// 스레드 2: counters.b += 1  을 반복
//
// 논리적으로는 전혀 겹치지 않는다. 그런데:
//   스레드 1이 a를 쓰면 → 그 캐시 라인 전체가 Modified
//   → 스레드 2의 사본은 Invalid
//   → 스레드 2가 b를 읽으려면 라인을 다시 가져와야 함
//   → 라인 소유권이 두 코어 사이를 계속 왕복 (ping-pong)
//
// 이게 false sharing 이다. "공유하지 않는데 공유된 것처럼 느려진다."

// ✅ 회피: 각자 다른 캐시 라인에 놓거나(패딩), 아예 스레드 로컬로 누적 후 합산
func parallelSum(_ items: [Int]) async -> Int {
    await withTaskGroup(of: Int.self) { group in
        // ⚠️ chunked(into:)는 표준 라이브러리에 없다 — 직접 정의하거나 stride를 쓴다
        for start in stride(from: 0, to: items.count, by: 1000) {
            let chunk = items[start..<min(start + 1000, items.count)]
            group.addTask { chunk.reduce(0, +) }   // 각자 지역 변수에 누적
        }
        return await group.reduce(0, +)            // 마지막에 한 번만 합침
    }
}

① 상호 배제 (Mutual Exclusion)   — 자원을 한 번에 하나만 쓸 수 있다
② 점유 대기 (Hold and Wait)      — 자원을 쥔 채로 다른 자원을 기다린다
③ 비선점  (No Preemption)        — 남의 자원을 강제로 뺏을 수 없다
④ 순환 대기 (Circular Wait)      — A→B→C→A 로 기다림이 순환한다

// → 하나만 깨면 데드락이 없어진다. 실무에서는 보통 ④를 깬다.

// ❌ 데드락 — 두 스레드가 반대 순서로 잠근다
func transferBad(_ from: Account, _ to: Account, _ amount: Int) {
    from.lock.lock()          // 스레드1: A잠금 → B대기
    to.lock.lock()            // 스레드2: B잠금 → A대기   → 순환 대기
    defer { to.lock.unlock(); from.lock.unlock() }
    from.balance -= amount; to.balance += amount
}

// ✅ 항상 같은 순서로 잠근다 (id 순) → 순환이 생길 수 없다
func transfer(_ from: Account, _ to: Account, _ amount: Int) {
    let (first, second) = from.id < to.id ? (from, to) : (to, from)
    first.lock.lock();  defer { first.lock.unlock() }
    second.lock.lock(); defer { second.lock.unlock() }
    from.balance -= amount; to.balance += amount
}

// ✅ 더 나은 해법: 락을 아예 안 쓴다 — 하나의 actor가 둘 다 소유
actor Bank {
    private var balances: [AccountID: Int] = [:]
    func transfer(_ from: AccountID, _ to: AccountID, _ amount: Int) {
        balances[from, default: 0] -= amount
        balances[to,   default: 0] += amount
    }   // await 없이 동기 코드 → 이 구간 전체가 원자적
}

// CAS의 의미: "지금 값이 expected 이면 desired로 바꿔라. 아니면 실패해라."
// 이 전체가 하드웨어 명령 하나로 원자적으로 수행된다.

// ── 의사코드: CAS 의 의미 ──
func compareAndSwap(_ ptr: inout Int, expected: Int, desired: Int) -> Bool

// 이걸로 락 없이 카운터를 만든다 (재시도 루프)
var current = load(counter)
while !compareAndSwap(&counter, expected: current, desired: current + 1) {
    current = load(counter)       // 누가 먼저 바꿨으면 다시 읽고 재시도
}

// ── 실제 Swift API: swift-atomics 패키지 ──
import Atomics
let counter = ManagedAtomic<Int>(0)
counter.wrappingIncrement(ordering: .relaxed)
let v = counter.load(ordering: .acquiring)

// 실제 CAS 는 결과를 튜플로 돌려준다
let (exchanged, original) = counter.compareExchange(
    expected: 0, desired: 1, ordering: .sequentiallyConsistent)

// ⚠️ 메모리 순서(ordering)를 직접 고르는 건 전문 영역이다.
//    .relaxed 는 순서 보장이 없어서 카운터에는 되지만 플래그에는 안 된다.
//    확신이 없으면 .sequentiallyConsistent 를 쓰거나, actor를 쓰는 게 낫다.