Cosa fare atomice nonatomicdire in dichiarazioni di proprietà?
@property(nonatomic, retain) UITextField *userName;
@property(atomic, retain) UITextField *userName;
@property(retain) UITextField *userName;
Qual è la differenza operativa tra questi tre?
Le ultime due sono identici; "atomica" è il comportamento predefinito ( si noti che non è in realtà una parola chiave, ma è specificato solo per l'assenza di - nonatomicatomicè stata aggiunta come parola chiave nelle versioni recenti di LLVM / clang).
Supponendo che si sta @synthesizing le implementazioni di metodo, atomiche contro i cambiamenti non-atomiche il codice generato. Se si sta scrivendo il proprio setter / getter, atomico / nonatomic / mantenere / assegnare / copia sono meramente consultivo. (Nota: @synthesize è ora il comportamento di default nelle versioni recenti di LLVM Non c'è nemmeno bisogno di dichiarare le variabili di istanza, verranno sintetizzati automaticamente, troppo, e avrà una. _Anteposto al loro nome a impedire l'accesso diretto accidentale).
Con "atomica", il setter / getter sintetizzato assicurerà che un intero valore viene sempre restituito dal getter o impostato dal setter, indipendentemente dall'attività setter su qualsiasi altro filo. Cioè, se filo A è nel mezzo del getter mentre il thread B chiama il setter, un valore effettivo praticabile - un oggetto autoreleased, molto probabilmente - sarà restituito al chiamante in A.
In nonatomic, tali garanzie sono fatti. Così, nonatomicè notevolmente più veloce di "atomica".
Quale "atomica" non non fare è fare alcuna garanzia circa la sicurezza thread. Se thread A chiama il getter simultaneamente con filo B e C chiamando il setter con valori diversi, filo A può ottenere uno qualsiasi dei tre valori restituiti - quello prima di qualsiasi setter vengono chiamati o uno dei valori passati nei incastonatori in B e C. Analogamente, l'oggetto può finire con il valore di B o C, c'è modo di dire.
Garantire l'integrità dei dati - una delle sfide primarie di programmazione multi-threaded - è ottenuto con altri mezzi.
Aggiungendo a questo:
atomicity di una singola proprietà, inoltre, non può garantire la sicurezza del filo quando più proprietà dipendenti sono in gioco.
Prendere in considerazione:
@property(atomic, copy) NSString *firstName;
@property(atomic, copy) NSString *lastName;
@property(readonly, atomic, copy) NSString *fullName;
In questo caso, filo A potrebbe essere rinominando l'oggetto chiamando setFirstName:e quindi chiamando setLastName:. Nel frattempo, filo B può chiamare fullNametra due chiamate filo di A e riceverà il nuovo nome accoppiato con il vecchio cognome.
Per far fronte a questo, è necessario un modello transazionale . Per esempio qualche altro tipo di sincronizzazione e / o esclusione che permette di escludere l'accesso alle fullNamementre le proprietà dipendenti vengono aggiornati.
Questo è spiegato in di Apple di documentazione , ma di seguito sono alcuni esempi di ciò che sta realmente accadendo. Si noti che non v'è alcuna parola chiave "atomica", se non si specifica "nonatomic" allora la proprietà è atomico, ma specificando "atomica" in modo esplicito si tradurrà in un errore.
//@property(nonatomic, retain) UITextField *userName;
//Generates roughly
- (UITextField *) userName {
return userName;
}
- (void) setUserName:(UITextField *)userName_ {
[userName_ retain];
[userName release];
userName = userName_;
}
Ora, la variante atomica è un po 'più complicato:
//@property(retain) UITextField *userName;
//Generates roughly
- (UITextField *) userName {
UITextField *retval = nil;
@synchronized(self) {
retval = [[userName retain] autorelease];
}
return retval;
}
- (void) setUserName:(UITextField *)userName_ {
@synchronized(self) {
[userName_ retain];
[userName release];
userName = userName_;
}
}
Fondamentalmente, la versione atomico deve prendere una serratura per garantire la sicurezza del filo, ed è anche urtando il conteggio ref sull'oggetto (e il conteggio autorelease per bilanciare) in modo che l'oggetto è garantito per esistere per il chiamante, altrimenti è una potenziale condizione di competizione se un altro thread sta impostando il valore, provocando il conteggio ref scenda a 0.
Ci sono in realtà un gran numero di diverse varianti di come queste cose funzionano a seconda che le proprietà sono valori scalari o oggetti, e come mantenere, copiare, in sola lettura, nonatomic, ecc interagire. In generale, i sintetizzatori di proprietà è sufficiente sapere come fare la "cosa giusta" per tutte le combinazioni.
Il modo migliore per capire la differenza sta usando il seguente esempio.
Supponiamo che ci sia una proprietà di stringa atomico chiamato "Nome", e se si chiama [self setName:@"A"]da filo A, chiamata [self setName:@"B"]dal filo B, e chiamata [self name]dal filo C, allora tutte le operazioni su diversi fili vengano eseguite in serie che significa che se un thread sta eseguendo una setter o getter, poi altri thread aspetteranno.
Questo rende proprietà "nome" leggere / scrivere al sicuro, ma se un altro thread, D, chiama [name release]contemporaneamente allora questa operazione potrebbe produrre un incidente perché non v'è alcuna chiamata setter / getter coinvolti qui. Il che significa un oggetto è di lettura / scrittura sicuro (atomico), ma non thread-safe come un altro thread possono contemporaneamente inviare alcun tipo di messaggi all'oggetto. Lo sviluppatore dovrebbe garantire thread-sicurezza per tali oggetti.
Se la proprietà "Nome" era nonatomic, allora tutte le discussioni nell'esempio sopra - A, B, C e D si eseguono realizzazione contemporanea alcun risultato imprevedibile. In caso di atomico, uno di A, B o C eseguirà prima, ma D può ancora eseguire in parallelo.
La sintassi e la semantica sono già ben definiti da altri eccellenti risposte a questa domanda. A causa di esecuzione e le prestazioni non sono descritti bene, vorrei aggiungere la mia risposta.
Qual è la differenza funzionale tra questi 3?
Avevo sempre considerato atomica come predefinito abbastanza curioso. A livello di astrazione lavoriamo a, utilizzando proprietà atomiche per una classe come veicolo per raggiungere il 100% thread safety è un caso d'angolo. Per i programmi multithreaded veramente corretti, intervento da parte del programmatore è quasi certamente un requisito. Nel frattempo, caratteristiche prestazionali ed esecuzione non sono ancora stati dettagliato in profondità. Dopo aver scritto alcuni programmi pesantemente multithread nel corso degli anni, mi era stato dichiaro le mie proprietà, come nonatomicper tutto il tempo perché atomica non era ragionevole per qualsiasi scopo. Durante la discussione dei dettagli di proprietà atomiche e nonatomic questa domanda , ho fatto un po 'di profilazione incontrato alcuni risultati curiosi.
Esecuzione
Ok. La prima cosa desidero chiarire è che l'attuazione di bloccaggio dipende dall'implementazione e sottratto. Louis utilizza @synchronized(self)nel suo esempio - ho visto questo come una fonte comune di confusione. L'implementazione non in realtà usa @synchronized(self); utilizza livello oggetto blocchi di selezione . Illustrazione di Louis è buono per un'illustrazione di alto livello utilizzando i costrutti siamo tutti a conoscenza, ma è importante sapere che non usa @synchronized(self).
Un'altra differenza è che le proprietà atomiche manterranno / ciclo di rilascio oggetti all'interno del getter.
Prestazione
Ecco la parte interessante: le prestazioni utilizzando la proprietà atomica accede a incontrastato (ad esempio single-threaded) casi può essere davvero molto veloce in alcuni casi. In meno che ideali casi, l'uso di accessi atomici può costare più di 20 volte il sovraccarico di nonatomic. Mentre il impugnato caso utilizzando 7 fili era 44 volte più lenta per la struct tre byte (2,2 GHz Core i7 Quad Core, x86_64). Struct tre byte è un esempio di una struttura molto lento.
Interessante nota a margine: funzioni di accesso definiti dall'utente della struct tre byte erano 52 volte più veloce rispetto alle funzioni di accesso atomiche sintetizzati; o 84% la velocità di funzioni di accesso nonatomic sintetizzati.
Oggetti in casi contestati anche in grado di superare i 50 orari.
A causa del numero di ottimizzazioni e variazioni nelle implementazioni, è abbastanza difficile da misurare l'impatto del mondo reale in questi contesti. Spesso si potrebbe sentire qualcosa come "Fidati, a meno che il profilo e scoprire che è un problema". A causa del livello di astrazione, è in realtà molto difficile da misurare l'impatto reale. Spigolatura costi effettivi da profili può richiedere molto tempo, ea causa di astrazioni, abbastanza impreciso. Come pure, ARC vs MRC può fare una grande differenza.
Quindi facciamo un passo indietro, non concentrandosi sull'attuazione della proprietà accessi, includeremo i soliti sospetti come objc_msgSend, ed esaminare alcuni risultati di alto livello del mondo reale per molti chiamate a un NSStringgetter in contestati casi (valori in secondi):
Come probabilmente avete indovinato, conteggio di riferimento l'attività / il ciclismo è un contributo significativo con Atomics e sotto ARC. Si potrebbe anche vedere maggiori differenze nei casi contestati.
Anche se ho prestare molta attenzione a prestazioni, ho ancora dire Semantica prima! . Nel frattempo, le prestazioni è una priorità bassa per molti progetti. Tuttavia, conoscendo i dettagli di esecuzione e costi delle tecnologie che si utilizzano di certo non fa male. Si dovrebbe usare la tecnologia giusta per le vostre esigenze, gli scopi e le abilità. Speriamo che questo vi farà risparmiare un paio d'ore di confronti, e vi aiutano a prendere una decisione più informati per la creazione di programmi.
Atomico = filo di sicurezza
Non-atomico = Nessun filo di sicurezza
variabili di istanza sono thread-safe se si comportano correttamente quando si accede da più thread, indipendentemente dalla programmazione o interleaving dell'esecuzione di tali fili dall'ambiente runtime, e senza sincronizzazione aggiuntivo o di coordinamento da parte del codice chiamante.
Se un thread modifica il valore dell'istanza il valore modificato è disponibile per tutti i fili, e solo un thread può modificare il valore alla volta.
atomic:se la variabile di istanza è gonna essere letta in un multithreading ambiente.
atomic:Non il più velocemente nonatomicperché nonatomicnon richiede alcun lavoro watchdog che dal runtime.
nonatomic:Se la variabile di istanza non è intenzione di essere modificato da più thread è possibile utilizzarlo. Migliora le prestazioni.
Ho trovato una spiegazione abbastanza ben messo di proprietà atomiche e non-atomiche qui . Ecco un testo rilevante della stessa:
'atomica' significa che non può essere suddiviso. In termini / programmazione OS una chiamata di funzione atomico è uno che non può essere interrotto - l'intera funzione deve essere eseguita, e non scambiato dalla CPU contesto abituale del sistema operativo di commutazione finché non è completa. Solo nel caso non lo sapeste: dal momento che la CPU può fare solo una cosa alla volta, il sistema operativo ruota accesso alla CPU a tutti i processi in esecuzione in poco tempo-fette, per dare la illusionedel multitasking. Lo scheduler CPU può (e lo fa) interrompere un processo in qualsiasi punto della sua esecuzione - anche chiamata di funzione metà. Quindi, per le azioni come l'aggiornamento condiviso variabili bancone dove due processi potrebbero tentare di aggiornare la variabile, allo stesso tempo, devono essere eseguiti 'atomico', vale a dire,
Quindi sarei indovinando che atomiche in questo caso significa i metodi lettore attributo non possono essere interrotti - a tutti gli effetti il che significa che la variabile (s) in fase di lettura con il metodo non può cambiare loro metà valore di strada attraverso perché qualche altro thread / call / funzione ottiene scambiato sulla CPU.
Poiché le atomicvariabili non possono essere interrotte, il valore contenuto in qualsiasi punto è (antisvitamento) garantita corrotta , anche se, garantendo questa frenafiletti rende l'accesso ad essi più lento. non-atomicvariabili, d'altra parte, non fanno tale garanzia, ma non offrono il lusso di un accesso più rapido. Per riassumere, andare con non-atomicquando sai le variabili non saranno accessibili da più thread contemporaneamente e le cose di velocità in su.
Dopo aver letto tanti articoli, Stack Overflow messaggi e facendo applicazioni demo per verificare gli attributi di proprietà variabili, ho deciso di mettere insieme tutte le informazioni attributi:
atomic // Predefinitononatomicstrong = retain // Predefinitoweak = unsafe_unretainedretainassign // Predefinitounsafe_unretainedcopyreadonlyreadwrite // PredefinitoNell'articolo attributi di proprietà variabili o modificatori in iOS è possibile trovare tutti gli attributi di cui sopra, e che sarà sicuramente aiutare.
atomic
atomic significa solo accesso filo variabile (tipo statico).atomic è thread sicuro.atomic è il comportamento predefinitoEsempio:
@property (retain) NSString *name;
@synthesize name;
nonatomic
nonatomic significa accesso multiplo filo variabile (tipo dinamico).nonatomic è thread-pericoloso.nonatomicNON è Default comportamento. Abbiamo bisogno di aggiungere la nonatomicparola chiave nella attributo di proprietà.Esempio:
@property (nonatomic, retain) NSString *name;
@synthesize name;
risposta più facile primo: non c'è alcuna differenza tra le seconde due esempi. Per impostazione predefinita, di accesso alle proprietà sono atomiche.
accessors atomici in un ambiente non garbage collection (ossia utilizzando trattenere / rilascio / autorelease) userà una serratura per assicurare che un altro filo non interferisce con la corretta impostazione / ottenendo del valore.
Vedere la " Prestazioni e Threading sezione" documentazione Objective-C 2.0 di Apple per qualche informazione in più e per altre considerazioni, quando la creazione di applicazioni multi-threaded.
garanzie atomici che accedono alla proprietà saranno eseguite in modo atomico. Ad esempio, si ritorna sempre a oggetti completamente inizializzato, qualsiasi get / set di una proprietà su un thread deve completare prima che un altro possa accedervi.
Se si immagina la seguente funzione che si verifica su due thread contemporaneamente si può vedere perché i risultati non sarebbero stati abbastanza.
-(void) setName:(NSString*)string
{
if (name)
{
[name release];
// what happens if the second thread jumps in now !?
// name may be deleted, but our 'name' variable is still set!
name = nil;
}
...
}
Pro: Restituzione dei beni completamente inizializzato ogni volta che lo rende la scelta migliore in caso di multi-threading.
Contro: calo di prestazioni, rende l'esecuzione di un po 'più lento
A differenza di Atomic, non garantisce oggetto completamente inizializzato tornare ogni volta.
Pro: l'esecuzione estremamente veloce.
Contro: Le probabilità di valore spazzatura in caso di multi-threading.
Atomic significa solo un thread accede alla variabile (tipo statico). Atomic è thread-safe, ma è lento.
Nonatomic significa più thread accedono alla variabile (tipo dinamico). Nonatomic è thread-pericoloso, ma è veloce.
Atomica è thread-safe , è lento ed esso pure assicura-(non garantito) che solo il valore bloccato è disponibile indipendentemente dal numero di fili tentano accesso sulla stessa zona. Quando si utilizza atomico, un pezzo di codice scritto all'interno di questa funzione diventa parte della sezione critica, a cui solo un thread può eseguire alla volta.
Assicura solo il filo di sicurezza; esso non garantisce che. Quello che voglio dire è di assumere un pilota esperto per la vostra auto, ancora non garanzie vettura non incontrare un incidente. Tuttavia, la probabilità rimane la minima.
Atomic - non può essere suddiviso, in modo che il risultato è previsto. Con nonatomic - quando un altro accesso filo zona di memoria può modificarlo, quindi il risultato è inaspettato.
Codice di conversazione:
Atomic rendere getter e setter della cassaforte filo proprietà. per esempio se u hanno scritto:
self.myProperty = value;
è thread sicuro.
[myArray addObject:@"Abc"]
NON è thread-safe.
Non esiste una parola chiave "atomica"
@property(atomic, retain) UITextField *userName;
Possiamo usare il sopra come
@property(retain) UITextField *userName;
Vedere Stack Overflow domanda io sono sempre problemi se uso @property (atomica, mantenere) NSString * myString .
Il valore predefinito è atomic, questo significa che non vi costerà prestazioni ogni volta che si utilizza la proprietà, ma è thread-safe. Nei Objective-C non, è impostato un blocco, in modo che solo il filo reale può accedere alla variabile, fino a quando viene eseguita la setter / getter.
Esempio con MRC di una proprietà con un _internal ivar:
[_internal lock]; //lock
id result = [[value retain] autorelease];
[_internal unlock];
return result;
Quindi, questi ultimi due sono gli stessi:
@property(atomic, retain) UITextField *userName;
@property(retain) UITextField *userName; // defaults to atomic
D'altra parte fa nonatomicaggiungono nulla al codice. Così è thread-safe solo se si codifica meccanismo di sicurezza da soli.
@property(nonatomic, retain) UITextField *userName;
Le parole chiave non deve essere scritto come attributo prima proprietà a tutti.
Non dimenticate, questo non significa che la proprietà nel suo complesso è thread-safe. Solo la chiamata al metodo del setter / getter è. Ma se si utilizza un setter e dopo che un getter al tempo stesso con 2 capi differenti, potrebbe essere rotto troppo!
atomica (default)
Atomic è il default: se non si digita nulla, la vostra proprietà è atomico. Una proprietà atomica è garantito che se si tenta di leggere da esso, si otterrà indietro un valore valido. Non fa alcuna garanzia su quello che potrebbe essere quel valore, ma si tornerà buoni dati, non solo la memoria spazzatura. Che cosa questo ti permette di fare è che se si dispone di più thread o processi multipli che punta a una singola variabile, un thread può leggere e un altro thread può scrivere. Se colpiscono allo stesso tempo, il thread di lettura è garantita per ottenere uno dei due valori: o prima della modifica o dopo il cambio. Quello atomica non dare è alcun tipo di garanzia su quale di questi valori si potrebbe ottenere. Atomic è davvero comunemente confuso con l'essere thread-safe, e che non è corretto. È necessario garantire la vostra sicurezza filo altri modi.
nonatomic
Il rovescio della medaglia, non atomico, come si può intuire, significa semplicemente, “non fare quella roba atomica.” Quello che si perde è quella garanzia che si ottiene sempre indietro qualcosa. Se si tenta di leggere nel bel mezzo di una scrittura, si potrebbe ottenere indietro i dati spazzatura. Ma, d'altra parte, si va un po 'più veloce. Perché proprietà atomiche hanno a che fare qualche magia per garantire che si otterrà indietro un valore, sono un po 'più lento. Se si tratta di una proprietà che si accede a un sacco, si consiglia di scendere fino a nonatomic per assicurarsi che non si incorrere quel rigore velocità.
Vedere più qui: https://realm.io/news/tmi-objective-c-property-attributes/
Come dichiarare:
Come atomica è di default in modo,
@property (retain) NSString *name;
E nel file di implementazione
self.name = @"sourov";
Supponiamo che un compito relativa a tre proprietà sono
@property (retain) NSString *name;
@property (retain) NSString *A;
@property (retain) NSString *B;
self.name = @"sourov";
Tutte le proprietà funzionano parallelamente (come in modo asincrono).
Se si chiama "nome" da filo A ,
E
Allo stesso tempo, se si chiama
[self setName:@"Datta"]
da filo B ,
Ora, se * proprietà name è nonatomic allora
Ecco perché non atomica è denominato filo pericoloso Ma ma è veloce in prestazioni a causa della esecuzione parallela
Ora, se * proprietà name è atomico
Ecco perché atomico è chiamato thread-safe e è per questo che si chiama lettura-scrittura sicura
Tale operazione situazione eseguirà serialmente. E Slow nelle prestazioni
- nonatomic significa multipla accesso filo (tipo dinamico) variabile.
- nonatomic è thread non sicuro.
- ma è veloce in termini di prestazioni
-Nonatomic NON è di default un comportamento, abbiamo bisogno di aggiungere parole chiave nonatomic in attributo di proprietà.
Per In Swift Confermando che le proprietà Swift sono nonatomic nel senso objC. Uno dei motivi è così ne pensate se per-proprietà atomicità è sufficiente per le vostre esigenze.
Riferimento: https://forums.developer.apple.com/thread/25642
Fro maggiori informazioni si prega di visitare il sito web http://rdcworld-iphone.blogspot.in/2012/12/variable-property-attributes-or.html
Se si utilizza la vostra proprietà nel codice multi-threaded, allora si sarebbe in grado di vedere la differenza tra gli attributi nonatomic e atomiche. Nonatomic è più veloce di atomica e atomica è thread-safe, non nonatomic.
Vijayendra Tripathi ha già dato un esempio di un ambiente multi-filettata.
Prima di iniziare: È necessario sapere che ogni oggetto in memoria deve essere deallocato dalla memoria per una nuova scrittura per accadere. Non si può semplicemente scrivere in cima a qualcosa come si fa sulla carta. È necessario prima cancellare (dealloc) e poi si può scrivere su di esso. Se nel momento in cui la cancellazione è fatto (o metà dell'opera) e nulla è ancora stato scritto (o mezzo ha scritto) e si tenta di leggere potrebbe essere molto problematico! Aiuto atomica e nonatomic ti trattano questo problema in vari modi.
Prima di leggere questo argomento e quindi leggere la risposta di Bbum . Oltre quindi leggere il mio riassunto.
atomic Sarà sempre garantire
Mantenere i conteggi sono il modo in cui la memoria è gestita in Objective-C. Quando si crea un oggetto, ha un conteggio di conservare 1. Quando si invia un oggetto di un messaggio conservare, mantenere il conteggio viene incrementato di 1. Quando si invia un oggetto un messaggio di rilascio, il suo conteggio trattenere viene decrementato di 1. Quando si inviare un oggetto di un messaggio autorelease , il suo conteggio trattenere viene decrementato di 1 a un certo punto in futuro. Se un object's mantengono conteggio viene ridotta a 0, viene deallocato.
Aspetta cosa?! Sono multithreading e la sicurezza dei thread diverso?
Sì. Multithreading significa: più thread possono leggere un pezzo condivisa di dati allo stesso tempo e non andrà in crash, ma non garantisce che non state leggendo da un valore non autoreleased. Con la sicurezza filo, è garantito che ciò che si legge, non è auto-rilasciato. La ragione per cui non facciamo tutto atomica di default è, perché non v'è un costo delle prestazioni e per la maggior parte delle cose che non si ha realmente bisogno di sicurezza thread. Alcune parti del nostro codice bisogno e per quei pochi pezzi che devono scrivere il codice in modo sicuro filo con serrature, mutex o la sincronizzazione.
nonatomic
Nel complesso sono diversi in 2 aspetti:
Crash o non a causa di avere o non avere piscina autorelease.
Consentendo da leggere proprio nel mezzo di un 'scrittura non è ancora terminata o valore vuoto' o non permettendo e consentendo solo da leggere quando il valore viene completamente scritto.
Prima di discutere sugli attributi di @property, si dovrebbe sapere che cosa è l'uso di @property. @property offre un modo per definire le informazioni che una classe è destinata a incapsulare. Se si dichiara un oggetto / variabile utilizzando @property, allora l'oggetto / variabile sarà accessibile ad altre classi di importazione della sua categoria. Se si dichiara un oggetto utilizzando @property nel file di intestazione, allora devi sintetizzare usando @synthesize nel file di implementazione.
Esempio:
classe .h
@interface ExampleClass : NSObject
@property (nonatomic, retain) NSString *name;
@end
classe .m
@implementation ExampleClass
@synthesize name;
@end
Ora il compilatore sintetizzerà metodi di accesso per nome.
ExampleClass *newObject=[[ExampleClass alloc]init];
NSString *name1=[newObject name]; // get 'name'
[obj setName:@“Tiger”];
Elenco degli attributi di @property: atomica. nonatomic. conservare. copia. sola lettura. leggere scrivere. assegnare. forte.
atomica: è il comportamento predefinito. Se un oggetto è dichiarato come atomica allora diventa thread-safe. mezzi a filo di sicurezza, in un tempo solo thread di un particolare esempio della classe possono avere il controllo su quell'oggetto.
Esempio :
@property NSString *name; //by default atomic
@property (atomic)NSString *name; // explicitly declared atomic
nonatomic: non è thread-safe. È possibile utilizzare l'attributo struttura nonatomic per specificare che accessors sintetizzati semplicemente impostare o restituire direttamente un valore, senza garanzie su ciò che accade se tale valore stesso si accede contemporaneamente da diversi thread. Per questo motivo, è più veloce per accedere a una proprietà nonatomic rispetto ad uno atomica.
@property (nonatomic)NSString *name;
mantenere: è richiesta quando l'attributo è un puntatore a un metodo setter object.The aumenterà mantenere conteggio dell'oggetto, in modo che occuperà memoria in pool autorelease.
@property (retain)NSString *name;
copia: se si utilizza la copia, non è possibile utilizzare conservare. Utilizzando esempio copia della classe conterrà la propria copia. Anche se una stringa mutabile è impostato e successivamente modificato, l'istanza di cattura qualunque valore che ha nel momento in cui viene impostata. saranno sintetizzati Nessun setter e getter metodi.
@property (copy) NSString *name;
NSMutableString *nameString = [NSMutableString stringWithString:@"Liza"];
xyzObj.name = nameString;
[nameString appendString:@"Pizza"];
in sola lettura: Se non si desidera consentire la proprietà da modificare tramite metodo setter, è possibile dichiarare la proprietà di sola lettura.
@property (readonly) NSString *name;
readwrite: è il comportamento predefinito. Non è necessario specificare l'attributo readwrite in modo esplicito.
@property (readwrite) NSString *name;
assegnare: genererà un setter che assegna il valore della variabile di istanza direttamente, piuttosto che copiare o suo mantenimento. Questa è la cosa migliore per i tipi primitivi come NSInteger e CGFloat, o gli oggetti non proprio direttamente, come ad esempio i delegati.
@property (assign) NSInteger year;
forte: è un sostituto per conservare.
@property (nonatomic, strong) AVPlayer *player;
unsafe_unretained: Ci sono alcune classi a Cocoa e Cocoa Touch che ancora non supportano riferimenti deboli, il che significa che non è possibile dichiarare una proprietà debole o variabile locale debole per tenere traccia di loro. Queste classi includono NSTextView, NSFont e NSColorSpace, ecc. Se è necessario utilizzare un riferimento debole per una di queste classi, è necessario utilizzare un riferimento non sicuro. Un riferimento non sicuro è simile ad un riferimento debole in quanto non tiene suo oggetto correlato vivo, ma non sarà impostato a zero se l'oggetto di destinazione si rilascia.
@property (unsafe_unretained) NSObject *unsafeProperty;
La struttura atomica assicura di mantenere un valore completamente inizializzato indipendentemente dal numero di fili stanno facendo getter & setter su di esso.
La proprietà nonatomic specifica che accessors sintetizzati semplicemente impostare o restituire un valore direttamente, senza garanzie su ciò che accade se tale valore stesso si accede contemporaneamente da diversi thread.
Atomic significa solo un thread può accedere alla variabile alla volta (tipo statico). Atomic è thread-safe, ma è lento.
Nonatomic significa più thread possono accedere alla variabile allo stesso tempo (tipo dinamico). Nonatomic è thread-pericoloso, ma è veloce.
Se si utilizza atomica, significa che il filo sarà al sicuro e di sola lettura. Se si utilizza nonatomic, significa che i più thread accedono variabile ed è filo pericoloso, ma viene eseguito rapidamente, fatta una lettura e scrittura; questo è un tipo dinamico.
Atomicità atomico (default)
Atomic è il default: se non si digita nulla, la vostra proprietà è atomico. Una proprietà atomica è garantito che se si tenta di leggere da esso, si otterrà indietro un valore valido. Non fa alcuna garanzia su quello che potrebbe essere quel valore, ma si tornerà buoni dati, non solo la memoria spazzatura. Che cosa questo ti permette di fare è che se si dispone di più thread o processi multipli che punta a una singola variabile, un thread può leggere e un altro thread può scrivere. Se colpiscono allo stesso tempo, il thread di lettura è garantita per ottenere uno dei due valori: o prima della modifica o dopo il cambio. Quello atomica non dare è alcun tipo di garanzia su quale di questi valori si potrebbe ottenere. Atomic è davvero comunemente confuso con l'essere thread-safe, e che non è corretto. È necessario garantire la vostra sicurezza filo altri modi. Tuttavia, atomic garantirà che se si tenta di leggere, si ritorna un qualche tipo di valore.
nonatomic
Il rovescio della medaglia, non atomico, come si può intuire, significa semplicemente, “non fare quella roba atomica.” Quello che si perde è quella garanzia che si ottiene sempre indietro qualcosa. Se si tenta di leggere nel bel mezzo di una scrittura, si potrebbe ottenere indietro i dati spazzatura. Ma, d'altra parte, si va un po 'più veloce. Perché proprietà atomiche hanno a che fare qualche magia per garantire che si otterrà indietro un valore, sono un po 'più lento. Se si tratta di una proprietà che si accede a un sacco, si consiglia di scendere fino a nonatomic per assicurarsi che non si incorrere quel rigore velocità. Accesso
cortesia https://academy.realm.io/posts/tmi-objective-c-property-attributes/
Attributi delle proprietà di atomicità (atomici e atomici) non si riflettono nella corrispondente dichiarazione di proprietà Swift, ma le garanzie atomicità dell'attuazione Objective-C ancora tengono quando la proprietà importato è accessibile da Swift.
Quindi - se si definisce una proprietà atomica in Objective-C rimarrà atomica quando viene utilizzato da Swift.
cortesia https://medium.com/@YogevSitton/atomic-vs-non-atomic-properties-crash-course-d11c23f4366c
Proprietà atomiche : - Quando una variabile associata con struttura atomica che significa che ha solo accesso filo e filo sarà sicuro e sarà bene in vista delle prestazioni, avrà comportamento predefinito.
Immobili non Atomic : - Quando una variabile assegnato con la proprietà atomica che significa che ha un accesso multi filo e non sarà thread-safe e sarà lento in vista delle prestazioni, avrà un comportamento di default e quando due thread diversi vogliono accedere variabile allo stesso tempo darà risultati imprevisti.
La verità è che usano spin lock per implementare proprietà atomica. Il codice, come di seguito:
static inline void reallySetProperty(id self, SEL _cmd, id newValue,
ptrdiff_t offset, bool atomic, bool copy, bool mutableCopy)
{
id oldValue;
id *slot = (id*) ((char*)self + offset);
if (copy) {
newValue = [newValue copyWithZone:NULL];
} else if (mutableCopy) {
newValue = [newValue mutableCopyWithZone:NULL];
} else {
if (*slot == newValue) return;
newValue = objc_retain(newValue);
}
if (!atomic) {
oldValue = *slot;
*slot = newValue;
} else {
spin_lock_t *slotlock = &PropertyLocks[GOODHASH(slot)];
_spin_lock(slotlock);
oldValue = *slot;
*slot = newValue;
_spin_unlock(slotlock);
}
objc_release(oldValue);
}
Per semplificare l'intera confusione cerchiamo di capire blocco mutex lock.Mutex secondo il nome blocca la mutevolezza del object.So se l'oggetto si accede da una classe nessun altra classe può accedere alla stessa @sychronise object.In IOS anche fornire il mutex lock.Now si servono in modalità FIFO e garantisce il flusso non è influenzato da due classi condividono lo stesso instance.However se l'attività è filo conduttore evitare oggetto che accede utilizzando proprietà atomiche come può tenere l'interfaccia utente e degradare le prestazioni
Atomic: Garantire thread-sicurezza bloccando il filo con NSLOCK.
Non atomico: Non garantire thread-sicurezza in quanto non v'è alcun meccanismo frenafiletti.