Quale dovrebbe essere il modo migliore in un'applicazione iOS per impedire che una variabile di istanza venga modificata da un oggetto mentre un'altra lo sta utilizzando? L'uso della direttiva @synchronized(self) dovrebbe essere sufficiente?Blocco di una variabile di istanza in Objective-C
Grazie in anticipo
Se l'unico scopo è quello di poter accedere
self.myString; //getter
e,
self.myString=aString; //setter
Il modo migliore è dichiarare come atomico, per esempio:
@property (atomic, strong) NSString* myString;
Ciò garantirà che in un ambiente con multithreading, l'impostazione e il recupero di myString dal thread 1 siano protetti dal thread 2 che fa qualcosa ad esso.
atomic! = thread safe – justin
Justin, permettimi di aggiornare la mia risposta per essere più chiara. – Spectravideo328
Se si desidera che un oggetto sia bloccato in modo che non vengano utilizzati contemporaneamente due thread contemporaneamente, @synchronize è a senso unico. But this does not make it thread-safe.
È inoltre possibile utilizzare GCD(Grand Central Dispatch) per lo stesso
Supponevo che '@ synchronize' (o uno degli altri meccanismi di sincronizzazione di una miriade) fosse usato precisamente per renderlo thread-safe. Certo, se lo fai male, non funzionerà. E, sì, ci sono modi migliori per ottenere il codice thread-safe (a la [Tips for Thread Safety] (https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Multithreading/ThreadSafety/ThreadSafety.html # // apple_ref/doc/uid/10000057i-CH8-SW6)). Ma a prescindere, puoi chiarire il punto che '@ synchronize' non lo rende thread-safe? Pensavo che fosse l'intero scopo delle tecniche di sincronizzazione. – Rob
@Rob: Finalmente lo trovo qui. Ho anche imparato questo in un'intervista: p –
Oh, mi sono perso per incollare: p http://stackoverflow.com/questions/10853529/locking-an-object-from-being-accessed-by-multiple-threads-objective-c –
Quale dovrebbe essere il modo migliore in un app iOS per evitare che una variabile di istanza venga modificata da un oggetto mentre un altro lo sta utilizzando?
Un buon vecchio blocco, come ad esempio pthread_mutex; potresti anche utilizzare un wrapper Objective-C di questo (ad esempio NSLock e NSRecursiveLock). @synchronized rientra anche in questa categoria, ma è il meccanismo di livello più elevato menzionato qui.
Ovviamente, le soluzioni concorrenti superiori in genere hanno più a che fare con le modifiche al design, il flusso del programma, favorendo l'immutabilità e così via. Ci saranno ancora casi in cui l'esclusione/blocco reciproco è preferito o richiesto.
Sfortunatamente, ObjC/Cocoa puro sono gravemente carenti in questo settore - lo sviluppo di un programma concorrente altamente efficiente utilizzando le tecnologie ObjC e Cocoa da solo è molto più difficile di quanto dovrebbe (o deve essere).
L'uso della direttiva @synchronized (auto) dovrebbe essere sufficiente?
Per casi semplici, è adeguato. È un livello oggetto Blocco ricorsivo.
Tuttavia, è piuttosto lento rispetto ad altre opzioni di esclusione reciproca.
Non credo @synchronized ha molto da offrire, oltre a:
@synchronized è conveniente, ma perché ha un costo elevato, va usata con giudizio.
è istanza var, non classe var .. e nessuno può dirti affidabilmente solo queste piccole informazioni –
È davvero una buona idea modificare una domanda ("variabile di classe" -> "variabile di istanza") se una * pensa * questo è ciò che intendeva l'OP? Leggendo la sua domanda precedente e la risposta, potrebbe essere che in realtà intendesse "variabile di classe". –
Scusate, colpa mia, avrei detto "variabile statica", è una bandiera il cui valore deve essere condiviso tra tutte le istanze della classe e assicurare che possa essere modificato solo da un'istanza a una determinata ora – AppsDev