Co wiesz o problemie czytelnika i pisarza?

Problem czytelnika i pisarza jest klasycznym zadaniem synchronizacji dostępu do wspólnych danych w środowisku wielowątkowym.

Istota problemu:

Wiele wątków (czytelników) odczytuje dane jednocześnie.
Wiele wątków (pisarzy) modyfikuje dane jednocześnie.

Wymagania:

Czytelnicy mogą czytać jednocześnie bez ograniczeń.
Pisarze mają wyłączny dostęp do danych (dopóki pisarz pracuje, nikt inny, ani czytelnik, ani pisarz, nie może uzyskać dostępu).
W tym samym czasie może pracować tylko jeden pisarz.
Jeśli pisarz oczekuje dostępu, nowi czytelnicy nie powinni go otrzymać, dopóki pisarz nie zakończy pracy. Ta zasada zapobiega "głodowi" pisarzy.

Rozwiązania w iOS:

NSLock: Najprostszy mechanizm, ale nieoptymalny dla tego zadania, ponieważ blokuje zarówno odczyt, jak i zapis.
NSRecursiveLock: Pozwala temu samemu wątkowi wielokrotnie uzyskać blokadę. Nie ma zastosowania.
NSCondition: Bardziej elastyczny mechanizm, pozwalający wątkom oczekiwać na spełnienie określonych warunków. Można go użyć do implementacji logiki czytelników/pisarzy, ale wymaga ręcznego zarządzania blokadami i warunkami.

Serial Dispatch Queue (GCD): Tworzenie jednej kolejki sekwencyjnej dla wszystkich operacji odczytu i zapisu. Zapis wykonywany jest synchronicznie, odczyt może być wykonywany asynchronicznie, ale tylko po zakończeniu poprzednich operacji. To proste rozwiązanie, ale nieoptymalne pod względem wydajności dla odczytu, ponieważ odczyt nie może być wykonywany równolegle.

let readWriteQueue = DispatchQueue(label: "com.example.readwrite", attributes: .concurrent)

func readData() {
    readWriteQueue.async {
        // Logika odczytu danych
        print("Odczyt danych...")
    }
}

func writeData() {
    readWriteQueue.sync(flags: .barrier) {
        // Logika zapisu danych
        print("Zapis danych...")
    }
}

Kolejka równoległa z barierą (GCD): Optymalne rozwiązanie w większości przypadków. Używa kolejki równoległej do wykonywania operacji odczytu równolegle. Do operacji zapisu używa się flagi .barrier. Gdy operacja z tą flagą jest umieszczona w kolejce, oczekuje na zakończenie wszystkich poprzednich operacji, następnie jest wykonywana, a podczas jej wykonywania żadna inna operacja (odczyt czy zapis) nie może się odbyć. Po zakończeniu kolejka wraca do stanu równoległego. W ten sposób odczyt jest równoległy, a zapis wyłączny.
```
let readWriteQueue = DispatchQueue(label: "com.example.readwrite", attributes: .concurrent)

func readData() {
    readWriteQueue.async {
        // Logika odczytu danych
        print("Odczyt danych...")
    }
}

func writeData() {
    readWriteQueue.sync(flags: .barrier) {
        // Logika zapisu danych
        print("Zapis danych...")
    }
}
```
To ten sam kod co dla kolejki sekwencyjnej, ale atrybut .concurrent sprawia, że kolejka jest równoległa. Flaga .barrier zmusza kolejkę do zachowania się jak sekwencyjna tylko dla tej konkretnej operacji.
os_unfair_lock (iOS 10+): Niskopoziomowe blokowanie, bardziej wydajne niż NSLock. Może być używane do ręcznego implementowania bardziej złożonej logiki czytelników/pisarzy, jeśli wymagana jest maksymalna wydajność lub specyficzne zachowanie. Wymaga ostrożnego użycia.

Wybór rozwiązania zależy od konkretnych wymagań aplikacji, częstotliwości operacji odczytu i zapisu oraz wymaganego poziomu wydajności. W większości przypadków, użycie równoległej kolejki dispatch z flagą .barrier jest najbardziej wyważonym i zalecanym podejściem w iOS.