스레딩 - Swift SDK

비동기 쓰기가 완료될 때까지 기다리기

SDK는 영역이 현재 비동기 쓰기를 수행하고 있는지 여부를 나타내는 Bool 를 제공합니다. isPerformingAsynchronousWriteOperations 변수는 다음 중 하나를 호출한 후 true 이(가) 됩니다.

• writeAsync

• beginAsyncWrite

• commitAsyncWrite

예약된 모든 비동기 쓰기 작업이 완료될 때까지 이 상태가 유지됩니다. 이 경우 영역이 닫히거나 무효화 되는 것은 차단됩니다.

비동기 쓰기 커밋 또는 취소

비동기 쓰기를 완료하려면 사용자 또는 SDK가 둘 중 하나를 호출해야 합니다:

• commitAsyncWrite

• 취소 동기화 쓰기

writeAsync 메서드를 사용하면 SDK가 트랜잭션 커밋 또는 취소를 처리합니다. 이는 객체 범위에 연결된 상태를 수동으로 유지할 필요 없이 비동기 쓰기의 편리함을 제공합니다. 그러나 writeAsync 차단 중에 명시적으로 호출하거나 commitAsyncWrite cancelAsyncWrite을(를) 수행할 수 있습니다. 이러한 메서드 중 하나를 호출하지 않고 반환하면 writeAsync도 반환됩니다.

• 쓰기 차단의 지침을 실행한 후 쓰기를 커밋합니다.

• 오류를 반환합니다.

두 경우 모두 writeAsync 작업이 완료됩니다.

비동기 쓰기 트랜잭션을 커밋하거나 취소할 시기를 더 효과적으로 제어하려면 beginAsyncWrite 메서드를 사용하세요. 이 방법을 사용하는 경우 트랜잭션을 명시적으로 커밋해야 합니다. 비동기 쓰기를 커밋하지 않고 반환하면 트랜잭션이 취소됩니다. beginAsyncWrite은(는) cancelAsyncWrite에 전달할 수 있는 ID를 반환합니다.

commitAsyncWrite 쓰기 트랜잭션을 비동기적으로 커밋합니다. 이 단계는 데이터를 Realm에 유지하는 단계입니다. commitAsyncWrite은(는) onComplete 차단을 가져갈 수 있습니다. 이 차단은 커밋이 완료되거나 오류로 인해 실패하면 소스 스레드에서 실행됩니다.

commitAsyncWrite을(를) 호출하면 즉시 반환됩니다. 이를 통해 SDK가 백그라운드 스레드에서 I/O를 수행하는 동안 호출자가 계속 진행할 수 있습니다. 이 메소드는 cancelAsyncWrite에 전달할 수 있는 ID를 반환합니다. 이렇게 하면 보류 중인 완료 차단 호출이 취소됩니다. 커밋 자체를 취소하지는 않습니다.

commitAsyncWrite에 대한 순차적 호출을 그룹화할 수 있습니다. 특히 배치된 트랜잭션이 작은 경우 이러한 호출을 배치하면 쓰기 성능이 향상됩니다. 트랜잭션 그룹화를 허용하려면 isGroupingAllowed 매개 변수를 true(으)로 설정합니다.

beginAsyncWrite 또는 commitAsyncWrite에서 cancelAsyncWrite을(를) 호출할 수 있습니다. beginAsyncWrite에서 호출하면 전체 쓰기 트랜잭션이 취소됩니다. commitAsyncWrite에서 호출하면 commitAsyncWrite에 전달했을 수 있는 onComplete 차단만 취소됩니다. 커밋 자체를 취소하지는 않습니다. 취소하려는 beginAsyncWrite 또는 commitAsyncWrite의 ID가 필요합니다.

백그라운드 스레드에서 Realm을 사용하기 위한 직렬 대기열 만들기

백그라운드 스레드에서 Realm을 사용하는 경우 직렬 대기열을 만듭니다. Realm은 global() 대기열과 같은 동시 대기열에서의 영역 사용을 지원하지 않습니다.

// Initialize a serial queue, and
// perform realm operations on it
let serialQueue = DispatchQueue(label: "serial-queue")
serialQueue.async {
    let realm = try! Realm(configuration: .defaultConfiguration, queue: serialQueue)
    // Do something with Realm on the non-main thread
}

스레드 간 인스턴스 전달

Realm, Results, List 및 관리되는 Objects 인스턴스는 스레드로 제한됩니다. 즉, 해당 항목을 만든 스레드에서만 사용할 수 있습니다. 그러나 Realm은 스레드 세이프 참조 메커니즘을 제공하여 한 스레드에서 생성된 인스턴스를 다른 스레드로 복사할 수 있습니다.

let realm = try! Realm()
let person = Person(name: "Jane")
try! realm.write {
    realm.add(person)
}
// Create thread-safe reference to person
@ThreadSafe var personRef = person
// @ThreadSafe vars are always optional. If the referenced object is deleted,
// the @ThreadSafe var will be nullified.
print("Person's name: \(personRef?.name ?? "unknown")")
// Pass the reference to a background thread
DispatchQueue(label: "background", autoreleaseFrequency: .workItem).async {
    let realm = try! Realm()
    try! realm.write {
        // Resolve within the transaction to ensure you get the
        // latest changes from other threads. If the person
        // object was deleted, personRef will be nil.
        guard let person = personRef else {
            return // person was deleted
        }
        person.name = "Jane Doe"
    }
}

func someLongCallToGetNewName() async -> String {
    return "Janet"
}
@MainActor
func loadNameInBackground(@ThreadSafe person: Person?) async {
    let newName = await someLongCallToGetNewName()
    let realm = try! await Realm()
    try! realm.write {
        person?.name = newName
    }
}
@MainActor
func createAndUpdatePerson() async {
    let realm = try! await Realm()
    
    let person = Person(name: "Jane")
    try! realm.write {
        realm.add(person)
    }
    await loadNameInBackground(person: person)
}
await createAndUpdatePerson()

let person = Person(name: "Jane")
let realm = try! Realm()
try! realm.write {
    realm.add(person)
}
// Create thread-safe reference to person
let personRef = ThreadSafeReference(to: person)
// Pass the reference to a background thread
DispatchQueue(label: "background", autoreleaseFrequency: .workItem).async {
    let realm = try! Realm()
    try! realm.write {
        // Resolve within the transaction to ensure you get the latest changes from other threads
        guard let person = realm.resolve(personRef) else {
            return // person was deleted
        }
        person.name = "Jane Doe"
    }
}

extension Realm {
    func writeAsync<T: ThreadConfined>(_ passedObject: T, errorHandler: @escaping ((_ error: Swift.Error) -> Void) = { _ in return }, block: @escaping ((Realm, T?) -> Void)) {
        let objectReference = ThreadSafeReference(to: passedObject)
        let configuration = self.configuration
        DispatchQueue(label: "background", autoreleaseFrequency: .workItem).async {
            do {
                let realm = try Realm(configuration: configuration)
                try realm.write {
                    // Resolve within the transaction to ensure you get the latest changes from other threads
                    let object = realm.resolve(objectReference)
                    block(realm, object)
                }
            } catch {
                errorHandler(error)
            }
        }
    }
}

let realm = try! Realm()
let readEmails = realm.objects(Email.self).where {
    $0.read == true
}
realm.writeAsync(readEmails) { (realm, readEmails) in
    guard let readEmails = readEmails else {
        // Already deleted
        return
    }
    realm.delete(readEmails)
}

여러 스레드에서 동일한 Realm 사용

스레드 간에 Realm 인스턴스를 공유할 수 없습니다.

여러 스레드에서 동일한 Realm 파일을 사용하려면 각 스레드에서 다른 Realm 인스턴스를 엽니다. 동일한 구성 을 사용하는 한 모든 Realm 인스턴스는 디스크의 동일한 파일에 매핑됩니다.

Realm 새로고침

Realm을 열면 가장 최근에 성공한 쓰기 커밋이 반영되며 새로 고침할 때까지 해당 버전으로 유지됩니다. 이는 Realm이 다음 새로 고침까지 다른 스레드에서 발생한 변경 사항을 볼 수 없음을 의미합니다. UI 스레드의 Realm, 더 정확하게는 이벤트 루프 스레드의 Realm은 해당 스레드의 루프가 시작될 때 자동으로 새로 고쳐집니다. 그러나 루프 스레드에 존재하지 않거나 자동 새로 고침이 비활성화된 Realm 인스턴스는 수동으로 새로 고침해야 합니다.

if (![realm autorefresh]) {
    [realm refresh]
}

if (!realm.autorefresh) {
   // Manually refresh
   realm.refresh()
}

동결된 객체

스레드에 제한된 라이브 개체는 대부분의 경우 잘 작동합니다. 그러나 일부 앱(예: 반응형 이벤트 스트림 기반 아키텍처를 기반으로 하는 앱)은 최종적으로 UI 스레드에 도달하기 전에 처리를 위해 불변의 복사본을 여러 스레드로 전송해야 합니다. 매번 딥 카피를 만드는 것은 비용이 많이 들고 Realm은 라이브 인스턴스를 스레드 간에 공유하는 것을 허용하지 않습니다. 이 경우 객체, 컬렉션 및 Realm을 동결 및 동결 해제할 수 있습니다.

동결하면 특정 객체, 컬렉션 또는 Realm에 대한 변경할 수 없는 보기가 생성됩니다. 동결된 객체, 컬렉션 또는 Realm은 여전히 디스크에 존재하며 다른 스레드로 전달될 때 딥 카피가 필요 없습니다. 스레드 문제에 대한 걱정 없이 스레드 간에 동결된 객체를 자유롭게 공유할 수 있습니다. Realm을 동결하면 그 하위 개체도 동결됩니다.

동결된 객체는 라이브 상태가 아니며 자동으로 업데이트되지 않습니다. 이는 사실상 정지 시점의 객체 상태에 대한 스냅샷입니다. 객체를 동결 해제하면 동결된 객체의 라이브 버전이 반환됩니다.

// Get an immutable copy of the realm that can be passed across threads
RLMRealm *frozenRealm = [realm freeze];
RLMResults *dogs = [Dog allObjectsInRealm:realm];
// You can freeze collections
RLMResults *frozenDogs = [dogs freeze];
// You can still read from frozen realms
RLMResults *frozenDogs2 = [Dog allObjectsInRealm:frozenRealm];
Dog *dog = [dogs firstObject];
// You can freeze objects
Dog *frozenDog = [dog freeze];
// To modify frozen objects, you can thaw them
// You can thaw collections
RLMResults *thawedDogs = [dogs thaw];
// You can thaw objects
Dog *thawedDog = [dog thaw];
// You can thaw frozen realms
RLMRealm *thawedRealm = [realm thaw];

let realm = try! Realm()
// Get an immutable copy of the realm that can be passed across threads
let frozenRealm = realm.freeze()
assert(frozenRealm.isFrozen)
let people = realm.objects(Person.self)
// You can freeze collections
let frozenPeople = people.freeze()
assert(frozenPeople.isFrozen)
// You can still read from frozen realms
let frozenPeople2 = frozenRealm.objects(Person.self)
assert(frozenPeople2.isFrozen)
let person = people.first!
assert(!person.realm!.isFrozen)
// You can freeze objects
let frozenPerson = person.freeze()
assert(frozenPerson.isFrozen)
// Frozen objects have a reference to a frozen realm
assert(frozenPerson.realm!.isFrozen)

동결된 객체로 작업할 때 다음 중 하나를 시도하면 예외가 발생합니다.

• 동결된 Realm에서 쓰기 트랜잭션 열기

• 동결된 객체 수정

• 동결된 Realm, 컬렉션 또는 객체에 변경 리스너 추가

isFrozen을(를) 사용하여 객체가 동결되었는지 확인할 수 있습니다 이는 항상 스레드로부터 안전합니다.

if ([realm isFrozen]) {
    // ...
}

if (realm.isFrozen) {
    // ...
}

동결된 객체는 해당 객체를 생성한 라이브 Realm이 열려 있는 한 유효합니다. 따라서 모든 스레드가 동결된 객체로 완료될 때까지 라이브 Realm을 닫지 않도록 합니다. 라이브 Realm이 닫히기 전에 동결된 Realm을 닫을 수 있습니다.

// Read from a frozen realm
let frozenPeople = frozenRealm.objects(Person.self)
// The collection that we pull from the frozen realm is also frozen
assert(frozenPeople.isFrozen)
// Get an individual person from the collection
let frozenPerson = frozenPeople.first!
// To modify the person, you must first thaw it
// You can also thaw collections and realms
let thawedPerson = frozenPerson.thaw()
// Check to make sure this person is valid. An object is
// invalidated when it is deleted from its managing realm,
// or when its managing realm has invalidate() called on it.
assert(thawedPerson?.isInvalidated == false)
// Thawing the person also thaws the frozen realm it references
assert(thawedPerson!.realm!.isFrozen == false)
// Let's make the code easier to follow by naming the thawed realm
let thawedRealm = thawedPerson!.realm!
// Now, you can modify the todo
try! thawedRealm.write {
   thawedPerson!.name = "John Michael Kane"
}

// Get a copy of frozen objects.
// Here, we're getting them from a frozen realm,
// but you might also be passing them across threads.
let frozenTimmy = frozenRealm.objects(Person.self).where {
    $0.name == "Timmy"
}.first!
let frozenLassie = frozenRealm.objects(Dog.self).where {
    $0.name == "Lassie"
}.first!
// Confirm the objects are frozen.
assert(frozenTimmy.isFrozen == true)
assert(frozenLassie.isFrozen == true)
// Thaw the frozen objects. You must thaw both the object
// you want to append and the collection you want to append it to.
let thawedTimmy = frozenTimmy.thaw()
let thawedLassie = frozenLassie.thaw()
let realm = try! Realm()
try! realm.write {
    thawedTimmy?.dogs.append(thawedLassie!)
}
XCTAssertEqual(thawedTimmy?.dogs.first?.name, "Lassie")

Git과 비교 및 대조

Git 과 같은 분산된 버전 관리 시스템에 익숙한 경우 를 사용하면 이미 MVCC를 직관적으로 이해하고 있을 수 있습니다. Git의 두 가지 기본 요소는 다음과 같습니다.

• 커밋, 즉 원자성 쓰기입니다.

• 브랜치, 즉 커밋 기록의 다른 버전입니다.

마찬가지로 Realm은 트랜잭션형태의 원자 단위로 커밋된 쓰기가 있습니다. 또한 Realm은 브랜치처럼 주어진 시간에 다양한 버전의 히스토리를 갖고 있습니다.

포크를 통한 배포와 분산을 적극적으로 지원하는 Git과 달리 Realm에는 항상 하나의 최신 버전만 있고 항상 최신 버전의 헤드에 데이터를 기록합니다. Realm은 이전 버전에 쓸 수 없습니다. 즉, 데이터가 하나의 최신 버전으로 수렴된다는 의미입니다.

내부 구조

영역은 B-트리 데이터 구조를 사용하여 구현됩니다. 최상위 노드는 영역의 버전을 나타냅니다. 하위 노드는 해당 버전의 영역에 있는 객체입니다. 영역은 Git이 HEAD 커밋에 대한 포인터를 갖는 것과 마찬가지로 최신 버전에 대한 포인터를 가지고 있습니다.

Realm은 쓰기 중 복사(copy-on-write) 기술을 사용하여 격리 를 보장합니다. 및 내구성 . 변경을 수행하면 Realm은 트리의 관련 부분을 복사하여 기록합니다. 그런 다음 Realm은 두 단계로 변경 사항을 커밋합니다.

• Realm은 변경 사항을 디스크에 기록하고 성공 여부를 확인합니다.

• 그런 다음 Realm은 최신 버전 포인터가 새로 작성된 버전을 가리키도록 설정합니다.

2단계 커밋 프로세스는 쓰기가 도중에 실패하더라도 트리의 관련 부분 복사본이 변경되었기 때문에 원래 버전이 어떤 식으로든 손상되지 않도록 보장합니다. 마찬가지로 Realm의 루트 포인터는 새 버전이 유효하다는 것이 보장될 때까지 원본 버전을 가리킵니다.

예제

다음 다이어그램은 커밋 프로세스를 보여줍니다.

클릭하여 확대

1. Realm은 트리 구조로 되어 있습니다. Realm에는 최신 버전인 V1에 대한 포인터가 있습니다.

2. 기록 시 Realm은 V1을 기반으로 V2 버전을 새로 만듭니다. Realm은 수정을 위해 객체의 복사본을 만들고(A ^1, C ¹) 수정되지 않은 객체에 대한 링크는 계속해서 원본 버전(B, D)을 가리킵니다.

3. 커밋을 확인한 후 Realm은 포인터를 새로운 최신 버전인 V2로 업데이트합니다. 그런 다음 Realm은 더 이상 트리에 연결되지 않은 오래된 노드를 버립니다.

Realm은 메모리 매핑과 같은 제로 카피 기술을 사용하여 데이터를 처리합니다. Realm에서 값을 읽으면 복사본이 아닌 사실상 실제 디스크 값을 보는 것입니다. 이는 라이브 객체의 기본이며 디스크 쓰기가 검증된 후 Realm 헤드 포인터가 새 버전을 가리키도록 설정할 수 있는 이유이기도 합니다.