Sto discutendo se passare o meno a un modello basato su GCD per accessors multi-thread. Ho utilizzato la sincronizzazione basata su lock personalizzata in accessor per anni, ma ho trovato alcune informazioni (Intro to GCD) e sembra che ci siano pro di un approccio basato su GCD. Spero di aprire qui un dialogo per aiutare me stesso e gli altri a valutare la decisione.Accessori Objective-C multi-thread: GCD vs lock
Il modello si presenta come:
- (id)something
{
__block id localSomething;
dispatch_sync(queue, ^{
localSomething = [something retain];
});
return [localSomething autorelease];
}
- (void)setSomething:(id)newSomething
{
dispatch_async(queue, ^{
if(newSomething != something)
{
[something release];
something = [newSomething retain];
[self updateSomethingCaches];
}
});
}
Sul lato pro: si ottiene il beneficio di, forse, non bloccando l'accesso in scrittura; più basso overhead di serrature (forse?); sicurezza dal dimenticare di sbloccare prima di tornare da sezioni di codice critiche; altri?
Contro: La gestione delle eccezioni è inesistente, quindi è necessario codificarlo in ogni blocco in cui potrebbe essere necessario.
Questo modello è potenzialmente il metodo consigliato per la scrittura di accessori multithread?
Esistono approcci standard per la creazione di code di invio per questo scopo? In altre parole, le migliori pratiche per il trading fuori dalla granularità? Ad esempio, con i blocchi, il blocco su ciascun attributo ha una grana più fine rispetto al blocco sull'intero oggetto. Con le code di invio, potevo immaginare che la creazione di una singola coda per tutti gli oggetti creava colli di bottiglia nelle prestazioni, quindi le code per oggetto sono appropriate? Ovviamente, la risposta dipende in larga misura dall'applicazione specifica, ma ci sono noti compromessi in termini di prestazioni per valutare la fattibilità dell'approccio.
Qualsiasi informazione/intuizione sarebbe apprezzata.
Proprio come un punto dati, le code e i blocchi pthread hanno un 'peso' simile (80 byte contro 64 byte, tempo di acquisizione comparabile), ma l'uso di code anziché di thread espliciti consente di risparmiare memoria cablata per i thread lato kernel (a meno che tu non gestisci con cura la tua vita thread esplicita te stesso tramite una sorta di pool) –