Qual è la differenza tra l'atomica e nonatomic attributi?

StackOverflow https://stackoverflow.com/questions/588866

Domanda

Cosa fare atomic e nonatomic media 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?

È stato utile?

Soluzione

Gli ultimi due sono identici; "Atomica" è il comportamento di default ( nota che non è in realtà una parola chiave, ma è specificato solo per l'assenza di nonatomic - atomic è stato aggiunto 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à un _ anteposto al loro nome per impedire l'accesso diretto accidentale.).

Con "atomica", il setter / getter sintetizzato garantirà che un tutto 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 -. Saranno restituiti al chiamante in A

In nonatomic, tali garanzie sono fatti. Così, nonatomic è notevolmente più veloce di "atomica".

Cosa "atomica" fa 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-thread -. È ottenuto con altri mezzi

In aggiunta a questo:

atomicity di una singola proprietà, inoltre, non può garantire la sicurezza dei thread quando più proprietà dipendenti sono in gioco.

Si consideri: 

 @property(atomic, copy) NSString *firstName;
 @property(atomic, copy) NSString *lastName;
 @property(readonly, atomic, copy) NSString *fullName;

In questo caso, filo A potrebbe essere rinomina l'oggetto chiamando setFirstName: e quindi chiamando setLastName:. Nel frattempo, filo B può chiamare fullName tra due chiamate filo di A e riceverà il nuovo nome accoppiato con il vecchio cognome.

Per risolvere questo problema, è necessario un modello transazionale . Cioè qualche altro tipo di sincronizzazione e / o esclusione che permette di escludere l'accesso alle fullName mentre le proprietà dipendenti vengono aggiornati.

Altri suggerimenti

Questo è spiegato in la documentazione di Apple , ma qui 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_;
    }
}

In sostanza, 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 , tuttavia v'è un 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 conservare, copiare, in sola lettura, nonatomic, ecc interagire. In generale, i sintetizzatori di proprietà è sufficiente sapere come fare la "cosa giusta" per tutte le combinazioni.

Atomic

  • è il comportamento di default
  • assicurerà il presente processo è completato dalla CPU, prima di un altro processo accede alla variabile
  • non è veloce, in quanto garantisce il processo è completato interamente

Non Atomic

  • non è il comportamento di default
  • più veloce (per il codice sintetizzato, vale a dire, per le variabili create utilizzando @property e @synthesize)
  • non thread-safe
  • può provocare un comportamento imprevisto, quando due differenti accessi processo la stessa variabile contemporaneamente

Il modo migliore per capire la differenza sta utilizzando il seguente esempio.

Supponiamo che ci sia una proprietà di stringa atomico chiamato "Nome", e se si chiama [self setName:@"A"] da filo A, chiamare [self setName:@"B"] dal filo B, e chiamare [self name] da filo C, allora tutte le operazioni su diversi fili vengano eseguite in serie che significa che se un thread sta eseguendo un setter o getter, poi altri thread aspetterà.

Questo rende proprietà "nome" di lettura / scrittura sicuro, ma se un altro thread, D, chiama [name release] contemporaneamente, allora l'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ò continuare a eseguire in parallelo.

La sintassi e la semantica sono già ben definiti da altri eccellenti risposte a questa domanda. Perché esecuzione e prestazioni non sono dettagliate bene, vorrei aggiungere la mia risposta.

  

Qual è la differenza funzionale tra questi 3?

Ho sempre considerato atomica come predefinito abbastanza curioso. A livello di astrazione, lavoriamo nell'uso proprietà atomiche per una classe come veicolo per raggiungere il 100% thread-sicurezza è 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 nonatomic 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 effettivamente uso @synchronized(self); utilizza livello di oggetto spin lock . 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.

Performance

Ecco la parte interessante: le prestazioni utilizzando la proprietà atomica accessi nei casi (single-threaded per esempio) incontrastato 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 lenta.

Interessante nota a margine: funzioni di accesso definiti dall'utente della struct tre byte sono stati 52 volte più veloce rispetto alle funzioni di accesso atomiche sintetizzati; o 84% la velocità di funzioni di accesso nonatomic sintetizzati.

Gli oggetti in casi contestati possono anche 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 le chiamate a un NSString getter in incontrastato casi (valori in secondi):

  • MRC | nonatomic | getter implementate manualmente: 2
  • MRC | nonatomic | getter sintetizzato: 7
  • MRC | atomic | getter sintetizzato: 47
  • ARC | nonatomic | getter sintetizzato: 38 (nota: di ARC aggiunta di conteggio ref ciclismo qui)
  • ARC | atomic | getter sintetizzato: 47

Come probabilmente avete indovinato, l'attività di conteggio di riferimento / il ciclismo è un contributo significativo con Atomics e sotto ARC. Si potrebbe anche vedere greatedifferenze r in casi contestati.

Anche se ho prestare molta attenzione alle prestazioni, ho ancora dire Semantica prima! . Nel frattempo, le prestazioni è una priorità bassa per molti progetti. Tuttavia, conoscendo i particolari 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ù informate per la creazione di programmi.

Atomic = filo di sicurezza

non-atomica = Nessun filo di sicurezza

Sicurezza Discussione:

variabili istanza sono thread-safe se si comportano correttamente quando si accede da più thread, indipendentemente dalla programmazione o interleaving dell'esecuzione di tali fili nel ambiente di esecuzione, e senza sincronizzazione aggiuntivo o di coordinamento da parte del chiamante codice.

Nel nostro contesto:

Se un thread cambia il valore dell'istanza il valore modificato è disponibile per tutti i fili, e solo un thread può modificare il valore alla volta.

Dove utilizzare atomic:

se la variabile di istanza sta andando essere letta in un ambiente con multithreading.

Coinvolgimento atomic:

Non veloce come nonatomic perché nonatomic non richiede alcun lavoro watchdog che dal tempo di esecuzione.

Dove utilizzare nonatomic:

Se la variabile di istanza non è intenzione di essere modificato da più thread è possibile utilizzarlo. Migliora le prestazioni.

Ho trovato abbastanza ben messo spiegazione atomica e non atomica proprietà qui.Ecco alcuni dei testi rilevanti della stessa:

'atomica' significa che non possono essere disaggregati.In OS/termini di programmazione atomica chiamata di funzione è uno che non può essere interrotta - l'intera funzione deve essere eseguita, e non lo swapping della CPU e il sistema operativo del contesto abituale di commutazione fino a quando è completo.Solo nel caso in cui non sapevi:dal momento che la CPU può fare solo una cosa alla volta, il sistema operativo gira l'accesso alla CPU per tutti i processi in esecuzione in poco tempo-fette, per dare il illusione di multitasking.La CPU scheduler può interrompere un processo in qualsiasi punto della sua esecuzione - anche a metà chiamata di funzione.Così per azioni, come ad esempio l'aggiornamento condiviso contatore variabili in cui due processi potrebbero tentare di aggiornare la variabile al tempo stesso, devono essere eseguite "singolarmente", cioè, di ogni operazione di aggiornamento è di finire nella sua interezza prima di qualsiasi altro processo può essere scambiato nella CPU.

Quindi mi piacerebbe essere indovinando che atomici in questo caso significa che l'attributo lettore metodi non può essere interrotto, in effetti, il che significa che la variabile(s) di essere a letto con il metodo non può cambiare il loro valore a metà strada attraverso a causa di alcuni altri thread/chiamata/funzione viene scambiato sulla CPU.

Perché il atomic le variabili non può essere interrotto, il valore contenuto da loro in qualsiasi punto (filo-lock) garantiti non corrotto, anche se , per garantire che questo thread lock accesso più lento. non-atomic le variabili, invece, di queste garanzie, ma non offrono il lusso di un accesso più rapido.Per riassumere, andare con non-atomic quando sai che il tuo variabili non saranno accessibili da più thread contemporaneamente e accelerare le cose.

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:

  1. atomic // default
  2. nonatomic
  3. strong = retain // default
  4. weak = unsafe_unretained
  5. retain
  6. assign // default
  7. unsafe_unretained
  8. copy
  9. readonly
  10. readwrite // default

Nell'articolo immobili variabile attributi o modificatori in iOS è possibile trovare tutti gli attributi di cui sopra, e che sicuramente vi aiuterà.

  1. atomic

    • atomic significa solo accesso filo variabile (tipo statico).
    • atomic è thread-safe.
    • Ma è lento in termini di prestazioni
    • atomic è il comportamento di default
    • accessors atomiche in un ambiente non garbage collection (cioè quando utilizza mantenere / release / autorelease) userà una serratura per assicurare che un altro filo non interferisce con la corretta impostazione / ottenendo del valore.
    • Non è in realtà una parola chiave.

    Esempio: 

        @property (retain) NSString *name;

    @synthesize name;

  2. nonatomic

    • nonatomic significa accesso multiplo filo variabile (tipo dinamico).
    • nonatomic è thread-pericoloso.
    • Ma è veloce in termini di prestazioni
    • nonatomic non è un comportamento di default. Abbiamo bisogno di aggiungere la parola chiave nonatomic nel attributo di proprietà.
    • Si può causare il comportamento imprevisto, quando due differenti processi (thread) accedere alla stessa variabile allo stesso tempo.

    Esempio: 

        @property (nonatomic, retain) NSString *name;

    @synthesize name;

Atomic:

garanzie Atomic che accedono alla proprietà saranno eseguite in modo atomico. Per 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 alla volta 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

non Atomic:

A differenza di Atomic, non garantisce oggetto completamente inizializzato tornare ogni volta.

Pro: esecuzione estremamente veloce.

Contro: Le probabilità di valore spazzatura in caso di multi-threading.

risposta più facile primo: non c'è alcuna differenza tra le seconde due esempi. Per impostazione predefinita, di accesso alle proprietà sono atomiche.

accessors atomiche in un ambiente raccolto non immondizia (cioè quando utilizza mantenere / release / autorelease) userà una serratura per assicurare che un altro filo non interferisce con la corretta impostazione / ottenendo del valore.

Vedere la " Prestazioni e Threading " della documentazione di Objective-C 2.0 di Apple per qualche informazione in più e per altre considerazioni, quando la creazione di applicazioni multi-threaded.

Atomic significa solo thread accede alla variabile (tipo statico). Atomic è thread-safe, ma è lento.

nonatomic significa più thread accedono al (tipo dinamico) variabile. Nonatomic è thread-non sicuro, ma è veloce.

Atomic è thread safe , è lenti e it pozzo assicura (non garantito) che solo il valore bloccato viene fornita indipendentemente come molti thread stanno tentando l'accesso nel corso della 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.

Si assicura solo il filo di sicurezza; esso non garantisce che. Quello che voglio dire è che si 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 thread accesso alla zona di memoria può modificarlo, quindi il risultato è inaspettato

Codice di conversazione:

Atomic rendere getter e setter del filo proprietà al sicuro. per esempio se u hanno scritto: 

self.myProperty = value;

è thread-safe. 

[myArray addObject:@"Abc"]

non è thread-safe.

Il default è atomic, questo significa che ti costa 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 la stessa: 

@property(atomic, retain) UITextField *userName;

@property(retain) UITextField *userName; // defaults to atomic

D'altra parte non fa nonatomic aggiungere nulla al codice. Quindi è thread-safe 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à di nuovo un valore valido. Non fa alcuna garanzia   su ciò che potrebbe essere quel valore, ma verranno restituiti buoni dati, non   solo la memoria spazzatura. Che cosa questo ti permette di fare è se si dispone di più   thread o più processi punta a una singola variabile, uno   thread può leggere e altro thread può scrivere. Se colpiscono allo stesso   tempo, il filo lettore è garantito per ottenere uno dei due valori:   sia prima la modifica o dopo il cambio. Quello atomica non lo fa   darvi è alcun tipo di garanzia su quale di quei valori che   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,   torni 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 è che garanzia che si   sempre tornare qualcosa. Se si tenta di leggere nel bel mezzo di un   scrive, 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 eliminare   verso il basso per nonatomic per assicurarsi che non si incorrere quella velocità   penalità.

Vedere più qui: https://realm.io/news/tmi-objective-c- Property attributi /

Se si sta utilizzando 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-threaded.

  • -Atomic significa solo accesso filo variabile (tipo statico).
  • -Atomic è thread-safe.
  • -ma è lento in termini di prestazioni

Come dichiarare:

Come atomica è di default in modo, 

@property (retain) NSString *name;

E nel file di implementazione 

self.name = @"sourov";

Si supponga 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" a partire da fili A ,

e

Allo stesso tempo, se si chiama 

[self setName:@"Datta"]

dal filo B ,

Ora, se * proprietà name è nonatomic , quindi

  • Si restituirà il valore "Datta" per A
  • Si restituirà il valore "Datta" per B

Ecco perché non atomica è denominato filo pericoloso Ma ma è veloce in prestazioni a causa della esecuzione parallela

Ora, se * proprietà name è atomico

  • Si garantirà valore "Sourov" per A
  • allora restituirà valore "Datta" per B

Ecco perché atomico è chiamato filo di sicurezza e Ecco perché si chiama lettura-scrittura sicura

Tale operazione situazione si esibirà in serie.   e lento in termini di prestazioni

- nonatomic mezzi multipli di accesso filo (tipo dinamico) variabile

.

- nonatomic è filo pericoloso

.

- 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 / variabile-proprietà-attributi-or.html

Prima di iniziare: È necessario sapere che ogni oggetto in memoria deve essere deallocato dalla memoria per un nuovo scrittore per accadere. Non si può semplicemente scrivere in cima a qualcosa come si fa sulla carta. È deve prima erase (dealloc) e poi si può scrivere su di esso. Se nel momento in cui la cancellazione è fatto (o metà dell'opera) e niente non ha ancora stato scritto (o mezzo ha scritto) e si tenta di leggere potrebbe essere molto problematico! aiuto atomica e nonatomic a trattare questo problema in vari modi.

Prima leggi questa domanda e poi leggere risposta di Bbum. Inoltre, quindi leggere la mia sintesi.

atomic SEMPRE garantire

  • Se due persone diverse vogliono leggere e scrivere allo stesso tempo, la carta non sarà solo bruciare! -.> L'applicazione non sarà mai in crash, anche in una condizione di competizione
  • Se una persona sta cercando di scrivere e ha scritto solo 4 degli 8 lettere da scrivere, quindi non può leggere nel mezzo, la lettura può essere fatto solo quando tutte le 8 lettere è scritto -> No read (ottenere) accadrà 'un filo che sta ancora scrivendo', vale a dire se ci sono 8 byte per byte da scrivere, e solo 4 byte sono scritti - fino a quel momento, non ti è permesso di leggere da esso. Ma da quando ho detto che non andrà in crash allora sarebbe leggere il valore di un autoreleased oggetto.
  • Se prima la scrittura sono cancellate quella che in precedenza era scritto su carta e poi qualcuno vuole leggere possono ancora leggere. Come? Sarete leggendo da qualcosa di simile a Mac OS Scomparto di rifiuti (non come cestino è ancora al 100% cancellata ... è in un limbo) ---> Se ThreadA è da leggere mentre ThreadB ha già deallocato di scrivere, si otterrebbe un valore da entrambi il valore finale completamente scritto da ThreadB o ottenere qualcosa dalla piscina autorelease.
  

mantieni conta sono il modo in cui la memoria è gestita in Objective-C.   Quando si crea un oggetto, ha un conteggio di mantenere 1. Quando si invia   un oggetto un mantenere messaggio, il suo conteggio di conservare viene incrementato di 1. Quando   si invia un oggetto un messaggio di rilascio, il suo conteggio trattenere viene decrementato   di 1. Quando si invia un oggetto un messaggio autorelease , il suo mantenere conteggio   è decrementato di 1 a un certo punto in futuro. Se un object's mantengono   conteggio viene ridotto a 0, viene deallocato.

  • Atomic non la sicurezza dei thread di garanzia, anche se è utile per il raggiungimento della sicurezza thread. Sicurezza discussione è relativo al modo in cui si scrive il codice / code che filo si sta leggendo / scrivendo da. Esso garantisce solo multithreading non crashable.

Che cosa ?! Sono multithreading e la sicurezza 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 è, che c'è 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, dobbiamo scrivere il codice in un modo thread-safe utilizzando serrature, mutex o la sincronizzazione.

nonatomic

  • Dal momento che non esiste una cosa del genere, come Mac OS cestino, quindi non importa a nessuno se o non si ottiene sempre un valore (<- Ciò potrebbe potenzialmente portare ad un crash), né nessun se ne frega se qualcuno tenta di leggere a metà strada attraverso il vostro per iscritto (anche se a metà strada scrivendo nel memory è molto diverso da metà scrittura su carta, sulla memoria potrebbe dare un pazzo valore stupido da prima, mentre sulla carta si vede solo la metà di ciò che è stato scritto) -> non garantisce di non mandare in crash, perché doesn' t meccanismo di uso autorelease.
  • Non garantisce valori di fondo scritto per essere letto!
  • è più veloce di atomica

Nel complesso sono diversi in 2 aspetti:

  • crash o non a causa di avere o non avere una piscina autorelease.

  • Consentire per essere letto proprio nel bel mezzo di una 'scrittura non è ancora finito o valore vuoto' o non permettendo e consentendo solo a leggere quando il valore è completamente scritto.

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 semplicemente impostare o restituire direttamente un valore sintetizzato, 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-non sicuro, ma è veloce.

Atomicità 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à di nuovo un valore valido. Non fa alcuna garanzia   su ciò che potrebbe essere quel valore, ma verranno restituiti buoni dati, non   solo la memoria spazzatura. Che cosa questo ti permette di fare è se si dispone di più   thread o più processi punta a una singola variabile, uno   thread può leggere e altro thread può scrivere. Se colpiscono allo stesso   tempo, il filo lettore è garantito per ottenere uno dei due valori:   sia prima la modifica o dopo il cambio. Quello atomica non lo fa   darvi è alcun tipo di garanzia su quale di quei valori che   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,   torni 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 è che garanzia che si   sempre tornare qualcosa. Se si tenta di leggere nel bel mezzo di un   scrive, 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 eliminare   verso il basso per nonatomic per assicurarsi che non si incorrere quella velocità   pena. Accesso

https://academy.realm.io/posts / TMI-Objective-C-proprietà-attributi /

attributi immobili Atomicity (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

di cortesia https://medium.com/@YogevSitton/ atomico-vs-non-atomico-proprietà-crash-corso-d11c23f4366c

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.

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);
    }

Proprietà atomiche : -. Quando una variabile assegnato con la proprietà atomica che significa che ha un solo accesso filo e sarà thread-safe e sarà un bene in vista delle prestazioni, avrà un comportamento di default

:

Proprietà atomica non : - 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 fili diversi vogliono accedere variabile allo stesso tempo darà risultati inaspettati.

Per semplificare l'intero confusione, cerchiamo di capire blocco mutex.

serratura Mutex, come da nome, blocca la mutevolezza dell'oggetto. Quindi, se l'oggetto si accede da una classe, nessun altra classe può accedere allo stesso oggetto.

In IOS, @sychronise fornisce anche il bloccaggio mutex .Now serve in modalità FIFO e garantisce il flusso non è influenzato da due classi condividono la stessa istanza. Tuttavia, se il compito è il filo conduttore, evitare l'oggetto che accede utilizzando le proprietà atomiche come può tenere il vostro 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

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top