Šta znate o problemu čitaoca i pisca?

Проблем читача и писца је класичан задатак синхронизације приступа заједничким подацима у окружењу са више нитова.

Суштина проблема:

Много нитова (читача) истовремено читају податке.
Много нитова (писаца) истовремено мењају податке.

Захтеви:

Читачи могу читати истовремено без ограничења.
Писаоци имају ексклузивни приступ подацима (док ради писац, нико други – ни читалац, ни писац – не може приступити).
Само један писац може радити истовремено.
Ако писац чека приступ, нови читаоци не би требало да добију приступ док писац не заврши свој посао. Ово правило спречава "глад" писаца.

Решења у iOS:

NSLock: Најједноставнији механизам, али није оптималан за овај задатак, јер блокира како читање, тако и писање.
NSRecursiveLock: Омогућава истом току да добије блокаду више пута. Не примењује се.
NSCondition: Флексибилнији механизам, омогућава токовима да чекају испуњење одређених услова. Може се користити за имплементацију логике читача/писаоца, али захтева ручно управљање блокадама и условима.
Serial Dispatch Queue (GCD): Креирање једне секвенцијалне реда за све операције читања и писања. Писања се извршавају синхроно, читање може бити асинхроно, али само након што се заврше претходне операције. Ово је једноставно решење, али није оптимално по учинку за читање, јер читање не може бити паралелно.
```
let readWriteQueue = DispatchQueue(label: "com.example.readwrite", attributes: .concurrent)

func readData() {
    readWriteQueue.async {
        // Логика читања података
        print("Читање података...")
    }
}

func writeData() {
    readWriteQueue.sync(flags: .barrier) {
        // Логика писања података
        print("Писање података...")
    }
}
```
Конкурентна редица са баријером (GCD): Најбоље решење у већини случајева. Користи конкурентну реду за паралелно извршавање операција читања. За операције писања се користи флаг .barrier. Када се операција са овим флагом стави у ред, она чека да се заврше све претходне операције, затим се извршава сама, и док се извршава, никакве друге операције (ни читање, ни писање) се не извршавају. После завршетка баријерске операције, реда поново постаје конкуретна. Тако, читање је паралелно, а писање ексклузивно.
```
let readWriteQueue = DispatchQueue(label: "com.example.readwrite", attributes: .concurrent)

func readData() {
    readWriteQueue.async {
        // Логика читања података
        print("Читање података...")
    }
}

func writeData() {
    readWriteQueue.sync(flags: .barrier) {
        // Логика писања података
        print("Писање података...")
    }
}
```
Ово је исти код као и за серијску реду, али атрибут .concurrent чини реду конкуретном. Флаг .barrier доводи реду да се понаша као секвенцијална само за ову конкретну операцију.
os_unfair_lock (iOS 10+): Ниско ниво закључавања, ефикасније од NSLock. Може се користити за имплементацију сложеније логике читача/писаоца ручно, ако је потребна максимална перформанса или специфично понашање. Захтева опрезну употребу.

Избор решења зависи од конкретних захтева апликације, учесталости операција читања и писања, и потребног нивоа перформансе. У већини случајева, коришћење конкуретне реде са флагом .barrier представља најбоље и најпрепорученије решење у iOS.