Blocco lettura-scrittura con GCD

Question

La mia applicazione fa un uso pesante di GCD e quasi tutto è suddiviso in piccole attività gestite da dispacci. Tuttavia, il modello di dati sottostante è principalmente letto e solo occasionalmente scritto.

Attualmente utilizzo blocchi per impedire modifiche alle strutture di dati critiche durante la lettura. Ma dopo aver esaminato i blocchi ancora oggi, ho trovato NSConditionLock e qualche pagina sui blocchi di lettura-scrittura. Quest'ultimo è esattamente ciò di cui ho bisogno.

Ho trovato questa implementazione: http://cocoaheads.byu.edu/wiki/locks. La mia domanda è: questa implementazione funzionerà con GCD, visto che usa PThreads?

Answer 1

Funzionerà ancora. pthreads è l'API di threading che sta alla base di tutte le altre API che usano thread su Mac OS X. (Sotto c'è l'attivazione del thread Mach, ma questo è SPI, non API.) Comunque, i lock pthreads non richiedono realmente l'uso di pthreads filettature.

Tuttavia, GCD offre un'alternativa migliore a partire da iOS 5: dispatch_barrier_async(). Fondamentalmente, hai una coda concorrente privata. Inviate tutte le operazioni di lettura ad esso nel modo normale. Sottoponi le operazioni di scrittura usando le routine di barriera. Ta-da! Blocco lettura-scrittura.

È possibile ottenere ulteriori informazioni a riguardo se si ha accesso allo WWDC 2011 session video for Session 210 - Mastering Grand Central Dispatch.

Answer 2

Si potrebbe anche voler considerare di mantenere una coda seriale per tutte le operazioni di lettura/scrittura. È quindi possibile scrivere dispatch_sync() in quella coda per garantire che le modifiche al modello di dati vengano applicate tempestivamente e dispatch_async() tutte le letture per assicurarsi di mantenere buone prestazioni nell'app.

Poiché si dispone di una singola coda seriale su cui si svolgono tutte le letture e le scritture, si garantisce che non si verifichino letture durante una scrittura. Questo è molto meno costoso di un blocco ma significa che non è possibile eseguire più operazioni di "lettura" contemporaneamente. È improbabile che questo causi un problema per la maggior parte delle applicazioni.

L'utilizzo di dispatch_barrier_async() può significare che le scritture effettuate richiedono una quantità arbitraria di tempo per essere effettivamente impegnate poiché tutte le attività preesistenti nella coda devono essere completate prima dell'esecuzione del blocco di barriera.